CVSS: 7.5EPSS: 0%CPEs: 4EXPL: 0CVE-2019-18625
https://notcve.org/view.php?id=CVE-2019-18625
An issue was discovered in Suricata 5.0.0. It was possible to bypass/evade any tcp based signature by faking a closed TCP session using an evil server. After the TCP SYN packet, it is possible to inject a RST ACK and a FIN ACK packet with a bad TCP Timestamp option. The client will ignore the RST ACK and the FIN ACK packets because of the bad TCP Timestamp option. Both linux and windows client are ignoring the injected packets. • https://github.com/OISF/suricata/commit/9f0294fadca3dcc18c919424242a41e01f3e8318 https://github.com/OISF/suricata/commit/ea0659de7640cf6a51de5bbd1dbbb0414e4623a0 https://lists.debian.org/debian-lts-announce/2020/01/msg00032.html https://redmine.openinfosecfoundation.org/issues/3286 https://redmine.openinfosecfoundation.org/issues/3395 •
CVSS: 9.1EPSS: 1%CPEs: 3EXPL: 2CVE-2019-18792
https://notcve.org/view.php?id=CVE-2019-18792
An issue was discovered in Suricata 5.0.0. It is possible to bypass/evade any tcp based signature by overlapping a TCP segment with a fake FIN packet. The fake FIN packet is injected just before the PUSH ACK packet we want to bypass. The PUSH ACK packet (containing the data) will be ignored by Suricata because it overlaps the FIN packet (the sequence and ack number are identical in the two packets). The client will ignore the fake FIN packet because the ACK flag is not set. • https://github.com/OISF/suricata/commit/1c63d3905852f746ccde7e2585600b2199cefb4b https://github.com/OISF/suricata/commit/fa692df37a796c3330c81988d15ef1a219afc006 https://lists.debian.org/debian-lts-announce/2020/01/msg00032.html https://redmine.openinfosecfoundation.org/issues/3324 https://redmine.openinfosecfoundation.org/issues/3394 • CWE-436: Interpretation Conflict •
CVSS: 5.3EPSS: 0%CPEs: 2EXPL: 0CVE-2019-17420
https://notcve.org/view.php?id=CVE-2019-17420
In OISF LibHTP before 0.5.31, as used in Suricata 4.1.4 and other products, an HTTP protocol parsing error causes the http_header signature to not alert on a response with a single \r\n ending. En OISF LibHTP versiones anteriores a 0.5.31, como es usado en Suricata versión 4.1.4 y otros productos, un error de análisis del protocolo HTTP hace que la firma http_header no avise en una respuesta con un solo \r\n al final. • https://github.com/OISF/libhtp/compare/0.5.30...0.5.31 https://github.com/OISF/libhtp/pull/213 https://redmine.openinfosecfoundation.org/issues/2969 • CWE-459: Incomplete Cleanup •
CVSS: 9.1EPSS: 0%CPEs: 1EXPL: 0CVE-2019-16410
https://notcve.org/view.php?id=CVE-2019-16410
An issue was discovered in Suricata 4.1.4. By sending multiple fragmented IPv4 packets, the function Defrag4Reassemble in defrag.c tries to access a memory region that is not allocated, because of a lack of header_len checking. Se detectó un problema en Suricata versión 4.1.4. Mediante el envío de múltiples paquetes IPv4 fragmentados, la función Defrag4Reassemble en el archivo defrag.c intenta acceder a una región de memoria que no está asignada, debido a una falta de comprobación de header_len. • https://lists.openinfosecfoundation.org/pipermail/oisf-announce https://suricata-ids.org/2019/09/24/suricata-4-1-5-released https://www.code-intelligence.com/cve-2019-16410 • CWE-125: Out-of-bounds Read •
CVSS: 9.8EPSS: 0%CPEs: 1EXPL: 0CVE-2019-16411
https://notcve.org/view.php?id=CVE-2019-16411
An issue was discovered in Suricata 4.1.4. By sending multiple IPv4 packets that have invalid IPv4Options, the function IPV4OptValidateTimestamp in decode-ipv4.c tries to access a memory region that is not allocated. There is a check for o->len < 5 (corresponding to 2 bytes of header and 3 bytes of data). Then, "flag = *(o->data + 3)" places one beyond the 3 bytes, because the code should have been "flag = *(o->data + 1)" instead. Se detectó un problema en Suricata versión 4.1.4. • https://lists.openinfosecfoundation.org/pipermail/oisf-announce https://suricata-ids.org/2019/09/24/suricata-4-1-5-released https://www.code-intelligence.com/cve-2019-16411 • CWE-125: Out-of-bounds Read •