Project

General

Profile

Bug #849

Not alerting on invalid http request Content-Length

Added by Peter Manev over 6 years ago. Updated 23 days ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

In the pcaps atatched
1) - http-events-abnormal-No-Content-Length.pcap
2) - http-events-abnormal-Invalid-Content-Length.pcap
3) - InvalidContentLengthApacheResponse.pcap
4) - ValidContentLengthApacheResponse.pcap

- 2) is with invalid content lenght - "Content-Length: 2040\r\n" added to the http request, packet 4.
- 1) is with the valid content length

In situation 2) wireshark does not recognize the http request - just recognizes it as valid TCP segment , which would be correct I think, since the content length is invalid.
Suricata recognizes 2) as a http request.

It is the exact same situation if the same is mirror but for the http response.

However the rules :

alert http any any -> any any (msg:"SURICATA HTTP invalid content length field in request"; flow:established,to_server; app-layer-event:http.invalid_content_length_field_in_request; flowint:http.anomaly.count,+,1; classtype:protocol-command-decode; sid:2221007; rev:1;)

alert http any any -> any any (msg:"SURICATA HTTP invalid content length field in response"; flow:established,to_client; app-layer-event:http.invalid_content_length_field_in_response; flowint:http.anomaly.count,+,1; classtype:protocol-command-decode; sid:2221008; rev:1;)


From http-events.rules do not generate an alert (or any of the rules in http-events.rules for that matter) in either respective case (request or response).

3) and 4) are the same case but real cases against Apache web server

Does not alert with 2.0dev (rev 5157ce1) or 1.4.3 or 2.0dev (rev cd7b4fa - latest git master )

Running Suri with:

suricata -c /etc/suricata/suricata.yaml -S /http-events.rules -r /root/Work/suricata/BUG/InvalidContentLength/http-events-abnormal-Invalid-Content-Length.pcap  --runmode=single

Thanks


Files

ContentLengthCaps.tar.gz (2.13 KB) ContentLengthCaps.tar.gz Peter Manev, 07/03/2013 07:42 AM
Content-length-bug-noxxi-de.pcap (94 KB) Content-length-bug-noxxi-de.pcap Peter Manev, 07/13/2013 11:19 AM

History

#1

Updated by Peter Manev over 6 years ago

Another such pacp added.

This is from the actual tool/website testing site added - http://noxxi.de/research/dubious-content-length.html
as reported by Will Metcalf.

Packet number 6 is one such case where the "Content-length" is 4891 but the actual data is 1448.

thanks

#2

Updated by Peter Manev over 6 years ago

Interesting addition -
with the pcap file Content-length-bug-noxxi-de.pcap - from the actuall test web page, 1.4.3 alerts 25 times, like so

07/13/2013-11:46:03.824560  [**] [1:2221008:1] SURICATA HTTP invalid content length field in response [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 37.221.197.243:8001 -> 192.168.1.71:4153
07/13/2013-11:46:03.691918  [**] [1:2221008:1] SURICATA HTTP invalid content length field in response [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 37.221.197.243:8001 -> 192.168.1.71:4144
07/13/2013-11:46:03.835038  [**] [1:2221008:1] SURICATA HTTP invalid content length field in response [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 37.221.197.243:8001 -> 192.168.1.71:4154
07/13/2013-11:46:03.794177  [**] [1:2221010:1] SURICATA HTTP unable to match response to request [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 37.221.197.243:8001 -> 192.168.1.71:4148

but git master - 2.0dev (rev 73e27c1) - does not alert.

Thanks

#3

Updated by Victor Julien almost 6 years ago

  • Target version set to TBD
#4

Updated by Andreas Herz about 3 years ago

  • Assignee set to OISF Dev
#5

Updated by Philippe Antoine 5 months ago

To me, the content length should now be handled fine after https://github.com/OISF/libhtp/commit/c0c87b4c560aae3850c7d90de1bdcb4fe966c9f0
That means :
- duplicate content-length headers with same value
- duplicate content-length headers with different values (first one is then used as http evader showed us that was the case for browsers)
- less or more data than content-length (but these do not generate an alert about the content length)

From your examples, it looks like you are expecting an alert when a connection is interrupted before the whole content length could have been sent.
Is this the case ?

#6

Updated by Victor Julien 4 months ago

Philippe can you turn the pcaps into suricata-verify tests?

#7

Updated by Philippe Antoine 3 months ago

Victor, to me, these are duplicates of the http evader cases (by the same person) https://noxxi.de/research/http-evader.html

#8

Updated by Victor Julien 23 days ago

So can this be closed Philippe Antoine ?

Also available in: Atom PDF