Bug #7556
openquic: valid traffic blocked in IPS mode
Added by Victor Julien 8 days ago. Updated about 23 hours 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 3 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 about 23 hours ago
Last pcap fixed with https://github.com/OISF/suricata/pull/12645
Updated by Philippe Antoine about 23 hours ago
- Status changed from In Review to Resolved