Bug #2881
openhttp.protocol parsing inaccuracy : accept spaces in URI
Description
Request:
GET /uid=0(root) gid=0(root) groups=0(root)asdf HTTP/1.1
User-Agent: curl/7.29.0
Accept: */*
eve.json output:"http":{"protocol":"gid=0(root) groups=0(root)asdf HTTP\/1.1"}
It appears that the http.protocol is matching too greedily with the space character and could use something like /\S+$/m
instead.
Files
Updated by chris lujan over 4 years ago
Conversely, the http.url field is only matching up until the first space resulting in something like:
"http":{"url":"/uid=0(root)"}
which leads me to believe those fields are created by splitting the line by spaces.
Updated by Victor Julien over 4 years ago
- Status changed from New to Assigned
- Assignee set to Philippe Antoine
- Target version set to TBD
Updated by Victor Julien over 4 years ago
I think uri's are not supposed to have spaces, but I think it would be good to address this anyway.
Updated by Philippe Antoine over 4 years ago
Thanks Chris.
Indeed, Uris are not supposed to have spaces, but the protocol field is even less supposed to have spaces.
So I think we can take the last space in the request line as the uri end, instead of the second one.
Updated by Philippe Antoine over 3 years ago
- Related to Task #3479: libhtp 0.5.33 (4.1.x) added
Updated by Philippe Antoine over 3 years ago
- Status changed from Assigned to In Review
Updated by Philippe Antoine over 3 years ago
- Target version changed from TBD to 6.0.0beta1
Updated by Philippe Antoine about 3 years ago
- Blocks Task #3824: libhtp 0.5.34 added
Updated by Victor Julien about 3 years ago
- Target version changed from 6.0.0beta1 to 6.0.0rc1
Updated by Victor Julien about 3 years ago
- Target version changed from 6.0.0rc1 to 7.0.0-beta1
Updated by Victor Julien about 3 years ago
- Blocks deleted (Task #3824: libhtp 0.5.34)
Updated by Philippe Antoine about 3 years ago
- Related to Task #3922: libhtp 0.5.35 added
Updated by Philippe Antoine almost 3 years ago
- Target version changed from 7.0.0-beta1 to 6.0.1
Updated by Philippe Antoine almost 3 years ago
- Related to Task #4180: libhtp 0.5.36 added
Updated by Victor Julien almost 3 years ago
- Target version changed from 6.0.1 to 7.0.0-beta1
Updated by Philippe Antoine almost 3 years ago
- Related to deleted (Task #4180: libhtp 0.5.36)
Updated by Philippe Antoine almost 3 years ago
https://github.com/OISF/suricata/pull/5599 for 6.0.1
For 7 :
changing the handling in 7 would be good, but I'm not sure it should be optional.
Updated by Philippe Antoine almost 3 years ago
https://github.com/OISF/suricata/pull/5614 merged for 6.0.1
Still work to do for 7
Updated by Philippe Antoine about 2 years ago
- Related to Task #4667: libhtp 0.5.39 added
Updated by Philippe Antoine over 1 year ago
https://github.com/OISF/suricata/pull/6884 is latest PR to review
Updated by Philippe Antoine about 1 year ago
- Priority changed from Normal to High
Updated by Victor Julien 11 months ago
- Target version changed from 7.0.0-beta1 to 7.0.0-rc1
Updated by Philippe Antoine 11 months ago
- Status changed from In Review to Closed
Updated by Victor Julien 8 months ago
- Status changed from Closed to In Review
- Priority changed from High to Normal
- Target version changed from 7.0.0-rc1 to 8.0.0-beta1
Was accidentally closed. Postponing once more to give rule writers more time to update things on their end.
Updated by Philippe Antoine 6 months ago
- Target version changed from 8.0.0-beta1 to 7.0.0-rc2
Updated by Philippe Antoine 5 months ago
Updated by Philippe Antoine 4 months ago
- Target version changed from 7.0.0-rc2 to 8.0.0-beta1
Updated by Brandon Murphy 4 months ago
- File b8ee56effed96ba.pcap b8ee56effed96ba.pcap added
I was testing the v16 fork of this and found a difference between 6.0.9 and v16. I was able to confirm the same behavior in v17 fork.
Current Behavior: When the v17 fork is presented with HTTP/1 Request which contains a double space after the URI and before the Protocol, the extra space is added to the end of the URI.
Expected Behavior: I expected the URI would be normalized and remove any trailing spaces, while the http.uri.raw buffer would contain the space.
alert http $HOME_NET any -> any any (msg:"Test Double Space after URI - alerts on 6.0.9"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"|2e|php"; endswith; sid:1;) alert http $HOME_NET any -> any any (msg:"Test Double Space after URI - alerts on v17"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"|2e|php|20|"; endswith; sid:2;)
Updated by Philippe Antoine 3 months ago
Thanks @Brandon Murphy for this report.
Would not the solution rather be to consider the URI before the last block of spaces ? (even the raw one)
Otherwise, SCHTPGenerateNormalizedUri
needs to add this normalization step (stripping spaces on the right)
Updated by Brandon Murphy 3 months ago
Would not the solution rather be to consider the URI before the last block of spaces ? (even the raw one)
When inconstancies or typos like a double space occur in malicious network traffic, we often use them when creating a rule. The ability to write signatures which can make use of these typos, such as the use of the double space, can provide for good fast_patterns in a rule, along with a low FP rate and the ability to very confidently attribute the traffic to a specific malware family/actor, etc.
I'm not sure where/how the best place to allow that to occur is (if not http.uri.raw
). Perhaps http.start
is the answer here? Based on https://github.com/OISF/suricata/pull/8869 it appears to have not been selected for "overloading" so that limits our use of http.start
Updated by Philippe Antoine 3 months ago
When inconstancies or typos like a double space occur in malicious network traffic, we often use them when creating a rule.
Indeed
Could http.request_line
be used in this case ?
Updated by Philippe Antoine 10 days ago
- Subject changed from http.protocol parsing inaccuracy to http.protocol parsing inaccuracy : accept spaces in URI