Bug #7556
openquic: valid traffic blocked in IPS mode
Added by Victor Julien 8 days ago. Updated 1 day ago.
Description
Missing handling of a fragmented Client Hello in Quic leads to the parser reaching an error state, which in IPS mode leads to blocking of the flow.
A quick and dirty workaround is to also set `QuicState::hello_ts` and `QuicState::hello_tc` on receiving these frags, but the real solution is to implement reassembly for the frags.
Files
Updated by Victor Julien 8 days ago
- File p3p1-0.5-us13.pcap p3p1-0.5-us13.pcap added
Updated by Philippe Antoine 5 days ago
- Status changed from Assigned to In Review
Updated by Victor Julien 5 days ago
- File 2231000-1739794908-192.168.0.5-38751-142.251.36.46-443.pcap 2231000-1739794908-192.168.0.5-38751-142.251.36.46-443.pcap added
Attached another example, here there are quite a lot of crypto frames split over 2 packets.
Updated by Victor Julien 5 days ago
- File 2231000-1739794855-192.168.0.5-52755-151.101.129.91-443.pcap 2231000-1739794855-192.168.0.5-52755-151.101.129.91-443.pcap added
Another pcap
Updated by Victor Julien 5 days ago ยท Edited
- File 2231000-1739796527-17.253.53.65-443-10.84.1.49-60015.pcap 2231000-1739796527-17.253.53.65-443-10.84.1.49-60015.pcap added
Not sure if this is a related issue, but this gave me a warning alert as well.
Updated by Philippe Antoine 5 days ago
Victor Julien wrote in #note-7:
Not sure if this is a related issue, but this gave me a
warningalert as well.
Not exactly related, but I pushed a simple fix and the SV test for this see https://github.com/OISF/suricata/pull/12593 latest commit
Updated by Victor Julien 4 days ago
- File wls3-quic-us29.pcap wls3-quic-us29.pcap added
Example of a server hello with out of order fragments.
Updated by Victor Julien 4 days ago
- File wls3-quic2-us7.pcap wls3-quic2-us7.pcap added
- File wls3-quic2-us13.pcap wls3-quic2-us13.pcap added
- File wls3-quic2-us19-weird-packet-number.pcap wls3-quic2-us19-weird-packet-number.pcap added
- File wls3-quic2-us670-pkn-32.pcap wls3-quic2-us670-pkn-32.pcap added
- File wls3-quic2-us1479.pcap wls3-quic2-us1479.pcap added
A few more interesting pcaps.
Updated by Philippe Antoine 4 days ago
I am adding a fix for wls3-quic2-us7.pcap
For wls3-quic2-us670-pkn-32.pcap it is strange to see packet 5 being protected before seeing the tls hello in packet 9
I do not see anything else interesting in the other pcaps (beyond my fix)
Updated by Victor Julien 3 days ago
- File wls3-quic3-us2041.pcap wls3-quic3-us2041.pcap added
- File wls3-quic3-us1398.pcap wls3-quic3-us1398.pcap added
- File wls3-quic3-us992.pcap wls3-quic3-us992.pcap added
A few more that generate alerts with the v5 branch (https://github.com/OISF/suricata/pull/12617)
Updated by Victor Julien 3 days ago
- File clipboard-202502191120-b98nf.png clipboard-202502191120-b98nf.png added
- File wls3-quic5-us124.pcap wls3-quic5-us124.pcap added
Another odd one.
Updated by Philippe Antoine 3 days ago
Victor Julien wrote in #note-13:
Another odd one.
This is a new one : quic retry packets (which reset the keys) handled in PR v7 with a new small commit
Updated by Victor Julien 2 days ago
- File clipboard-202502201225-vx4hq.png clipboard-202502201225-vx4hq.png added
- File wls3-quic9-us335.pcap wls3-quic9-us335.pcap added
Here is another odd one. Init, retry, init, retry. But it seems the last retry is invalid?
Updated by Philippe Antoine 1 day ago
Last pcap fixed with https://github.com/OISF/suricata/pull/12645
Updated by Philippe Antoine 1 day ago
- Status changed from In Review to Resolved