Bug #2117
closedbyte_extract and byte_test collaboration doesnt work on 3.2.1
Description
First of all, it doesnt work on 3.2.1 but works on 4.0dev currently.
The issue is when I extract a number from a string (content-length header value) by applying byte_extract to it and then compare it to another string number (http chunk size) by using byte_test it doesnt work as expected and it seems that 2nd number (chunk size) is compared to 0.
Find test sigs, pcap and suricata 3.2.1 output in attachment
Files
Updated by Victor Julien almost 7 years ago
- Status changed from New to Assigned
- Assignee set to Victor Julien
I'll try to figure out which commit(s) fixed it in master and if backporting is feasible.
Updated by Victor Julien almost 7 years ago
- Target version changed from 3.2.2 to 70
I've looked into this. Fixing this in 3.2.x is going to be too hard. In 4.0dev it works a bit by luck, and can easily made to break.
What happens is that the inspection happens in 2 different steps:
content: "Content-Length: "; nocase; http_header; byte_extract: 0, 0, contentlengthvalue, relative, string, dec;
This inspects the http_header buffer.
content: "|0D 0A 0D 0A|"; distance: 0; byte_test: 0, >, contentlengthvalue, 0, relative, string, hex; sid: 111;
This inspects the stream buffer.
In 3.2.x the stream buffer is always inspected before the HTTP header buffer. So the byte_test check runs (and fails) before the byte_extract runs.
In 4.0dev the buffer that has the 'fast_pattern' runs first. In this case this means the HTTP header buffer is inspected first. So then byte_extract runs before byte_test.
But it can be easily made to fail by forcing the fast_pattern to be on the stream pattern:
content: "Content-Length: "; nocase; http_header; byte_extract: 0, 0, contentlengthvalue, relative, string, dec; content: "|0D 0A 0D 0A|"; distance: 0; fast_pattern; byte_test: 0, >, contentlengthvalue, 0, relative, string, hex;
In this case the byte_extract runs after the byte_test again.
Solving this will require some thought and will likely be non-trivial. Perhaps simply rejecting such rules would be best for now.
Updated by Victor Julien almost 7 years ago
- Status changed from Assigned to Closed
- Target version changed from 70 to 4.0rc1
This was fixed in 4.0rc1. 3.2.x won't be fixed as it's too intrusive.