Actions
Bug #3186
closedMultiple Content-Length headers causes HTP_STREAM_ERROR (4.1.x)
Affected Versions:
Effort:
Difficulty:
Label:
Description
Summary:
Multiple Content-Length headers causes libhtp to stop parsing and return HTP_STREAM_ERROR.
Example rule:
alert http any any -> any any (msg:"HTTP Host Header"; flow:established, to_server; content:"Host|3A|"; http_header; sid:4567890;)
Example traffic (full pcap attached):
POST /submit.php HTTP/1.1 User-Agent: Mozilla Host: suricata-ids.org Content-Length: 45 Cache-Control: no-cache Content-Length: 45 foo=bar&a=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Debug output snippet:
htp_connp_REQ_HEADERS: ptr 0x2aec89ee9305 offset 0 len 20 00000000 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 |Content-Length: | 00000010 34 35 0d 0a |45..| Header name: ptr 0x1c2c2d58 offset 0 len 14 00000000 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 |Content-Length| Header value: ptr 0x1c2c2d88 offset 0 len 2 00000000 34 35 |45| htp_connp_REQ_HEADERS: ptr 0x2aec89ee9319 offset 0 len 2 00000000 0d 0a |..| htp_connp_req_data: returning HTP_STREAM_ERROR
Possible solutions:
If all Content-Lengh values are the same, continue as usual. If not, instead of aborting, something else could be done:
- Use the first one seen
- Use the last one seen
- Use the largest
- Use the smallest
My first thought is to go with use the smallest.
Notes:
This behavior tested/seen with Suricata 2.0.9 and 3.0.1, not with 1.3.4 though.
To do:
See how other multiple HTTP header names are handled, especially those that populate http_user_agent, http_host, and http_cookie buffers.
Actions