There are 14 open security issues in buster.
14 issues left for the package maintainer to handle:
- CVE-2019-10050:
(needs triaging)
A buffer over-read issue was discovered in Suricata 4.1.x before 4.1.4. If the input of the decode-mpls.c function DecodeMPLS is composed only of a packet of source address and destination address plus the correct type field and the right number for shim, an attacker can manipulate the control flow, such that the condition to leave the loop is true. After leaving the loop, the network packet has a length of 2 bytes. There is no validation of this length. Later on, the code tries to read at an empty position, leading to a crash.
- CVE-2019-10051:
(needs triaging)
An issue was discovered in Suricata 4.1.3. If the function filetracker_newchunk encounters an unsafe "Some(sfcm) => { ft.new_chunk }" item, then the program enters an smb/files.rs error condition and crashes.
- CVE-2019-10052:
(needs triaging)
An issue was discovered in Suricata 4.1.3. If the network packet does not have the right length, the parser tries to access a part of a DHCP packet. At this point, the Rust environment runs into a panic in parse_clientid_option in the dhcp/parser.rs file.
- CVE-2019-10053:
(needs triaging)
An issue was discovered in Suricata 4.1.x before 4.1.4. If the input of the function SSHParseBanner is composed only of a \n character, then the program runs into a heap-based buffer over-read. This occurs because the erroneous search for \r results in an integer underflow.
- CVE-2019-10054:
(needs triaging)
An issue was discovered in Suricata 4.1.3. The function process_reply_record_v3 lacks a check for the length of reply.data. It causes an invalid memory access and the program crashes within the nfs/nfs3.rs file.
- CVE-2019-10055:
(needs triaging)
An issue was discovered in Suricata 4.1.3. The function ftp_pasv_response lacks a check for the length of part1 and part2, leading to a crash within the ftp/mod.rs file.
- CVE-2019-10056:
(needs triaging)
An issue was discovered in Suricata 4.1.3. The code mishandles the case of sending a network packet with the right type, such that the function DecodeEthernet in decode-ethernet.c is executed a second time. At this point, the algorithm cuts the first part of the packet and doesn't determine the current length. Specifically, if the packet is exactly 28 long, in the first iteration it subtracts 14 bytes. Then, it is working with a packet length of 14. At this point, the case distinction says it is a valid packet. After that it casts the packet, but this packet has no type, and the program crashes at the type case distinction.
- CVE-2019-1010279:
(needs triaging)
Open Information Security Foundation Suricata prior to version 4.1.3 is affected by: Denial of Service - TCP/HTTP detection bypass. The impact is: An attacker can evade a signature detection with a specialy formed sequence of network packets. The component is: detect.c (https://github.com/OISF/suricata/pull/3625/commits/d8634daf74c882356659addb65fb142b738a186b). The attack vector is: An attacker can trigger the vulnerability by a specifically crafted network TCP session. The fixed version is: 4.1.3.
- CVE-2019-15699:
(needs triaging)
An issue was discovered in app-layer-ssl.c in Suricata 4.1.4. Upon receiving a corrupted SSLv3 (TLS 1.2) packet, the parser function TLSDecodeHSHelloExtensions tries to access a memory region that is not allocated, because the expected length of HSHelloExtensions does not match the real length of the HSHelloExtensions part of the packet.
- CVE-2019-16410:
(needs triaging)
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.
- CVE-2019-16411:
(needs triaging)
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.
- CVE-2019-18625:
(needs triaging)
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.
- CVE-2019-18792:
(needs triaging)
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. Both linux and windows clients are ignoring the injected packet.
- CVE-2021-35063:
(needs triaging)
Suricata before 5.0.7 and 6.x before 6.0.3 has a "critical evasion."
You can find information about how to handle these issues in the security team's documentation.
![[bug history graph]](https://qa.debian.org/data/bts/graphs/s/suricata.png){kind=link}