tcp.hdr content matches don't work as expected
While working on detecting the Urgent11 exploits for VxWorks, Victor Julian brought the ipv4.hdr and tcp.hdr keywords to my attention which are available in Suricata 5.0.
I tried using these keywords to match certain conditions (using CVE-2019-12260 as an example, see attachments).
The PCAP I tried to match on contains the following content from offset 20 - 24: "1D 03 61 00"
I tried to match this with the following Suricata rule to prove this is present:
alert tcp any any -> any any (msg:"EXPLOIT - Suricata 5.0 tcp.hdr test for CVE-2019-12260"; flow:to_server; tcp.hdr; content:"|1d 03 61 00|"; offset:20; depth:4; sid:1; rev:1;)
This will match packets: 3, 5, 6, 7, 9, and 10.
If I up the offset with 1, the following rule doesn't match at all (like you would expect):
alert tcp any any -> any any (msg:"EXPLOIT - Suricata 5.0 tcp.hdr test for CVE-2019-12260"; flow:to_server; tcp.hdr; content:"|1d 03 61 00|"; offset:21; depth:4; sid:1; rev:1;)
Adding the SYN flag to the rule will only match packets: 3, and 7. The only packet that should match in either of the above rules that match from offset 20 is packet 3. This can be verified by looking at the PCAP in Wireshark and looking for the hex values of "1D 03 61 00".
Before trying the content matches I was jumping straight into looking if the length option of the TCP option in packet 3 was indeed < 4 with the byte_test keyword, this also seems to work but with matching the same packets that were mentioned above (3, 5, 6, 7, 9, and 10).
I lack the understanding and knowledge of how the code for tcp.hdr works, but it looks like the sticky buffer carries its matches across the rest of the PCAP.
The script used to forge the packets is also included with the attachments, this is based on the technical whitepaper of Armis: https://armis.com/urgent11/
Operating System: Ubuntu 18.04 64-bit
Suricata version: 5.0.0 RELEASE (debian package)
Wireshark version: 2.6.10