3 ms·

Tool causes Apache web server to freeze

55 points by fvbock 15y ago

blameless 15y ago
"A previously unknown flaw in the code for processing byte range headers allows version 2.2.x of the Apache Web Server to be crippled from a single PC." It was pointed out in 2007 http://seclists.org/bugtraq/2007/Jan/83 http://seclists.org/bugtraq/2007/Jan/83 It also affects Apache 1.3.
mwill 15y ago
HN submission for the official advisory: http://news.ycombinator.com/item?id=2924156 http://news.ycombinator.com/item?id=2924156
blantonl 15y ago
are there any haproxy blocking solutions in place yet?
- pageman 15y ago
  found this: http://www.mail-archive.com/haproxy@formilux.org/msg05625.html http://www.mail-archive.com/haproxy@formilux.org/msg05625.ht... The following regexp works in HAProxy: ([0-9]+-[0-9]+) The same with the coma does not work: ([0-9]+-[0-9]+,) This one works: ([0-9]+-[0-9]+?) And this one does not: ([0-9]+-[0-9]+?)\{10,\}
- ominous_prime 15y ago
  yes, to quote Willy: What is needed is to remove the Range header when there are too many occurrences of it. Their attack puts up to 1300 Range values. Let's remove the header if there are more than 2 : reqidel ^Range if { hdr_cnt(Range) gt 2 } That should reliably defeat the attack.
  - kwantam 15y ago
    It's not just too many occurrences of the header, it's too many ranges specified in a particular header. The zero-day script submits a header that looks like this: Range:bytes=0-,5-1,5-2,5-3,5-4,...,5-1299 I don't know if you were implying something different with your answer since I'm not familiar enough with haproxy to know the semantics of hdr_cnt; I wanted to guard against ambiguity. A simple test of your own machine would be something like this: /bin/echo -en "HEAD / HTTP/1.1\r\nHost:localhost\r\nRange:bytes=0-,$(perl -e 'for ($i=1;$i<1300;$i++) { print "5-$i,"; }')5-1300\r\nAccept-Encoding:gzip\r\nConnection:close\r\n\r\n" | nc localhost 80
    - ominous_prime 15y ago
      Multi-valued headers and multiple headers are interchangeable as long long as the order of values is maintained. Haproxy therefor parses the two into the same internal representation, and the rule works for either.
      - thwarted 15y ago
        This is documented in haproxy's configuration.txt: hdr <string> hdr(header) <string> Note: all the "hdr*" matching criteria either apply to all headers, or to a particular header whose name is passed between parenthesis and without any space. The header name is not case-sensitive. The header matching complies with RFC2616, and treats as separate headers all values delimited by commas. Use the shdr() variant for response headers sent by the server.
toong 15y ago
This doesn't seem to be very effective on my test system (apache2-mpm-prefork 2.2.14-5ubuntu8.4) regarding memory usage triggering the oom-killer. Memory seems to be (almost?) stable, but apache cpu usage is through the roof, with the client barely consuming any cpu. The moment you kill the client, the apache server is back ok. I'll let it run for another hour or so, to see that this actually gets somewhere or not. Are the actual memory increments really small and/or slow ? Or isn't this supposed to work with the apache2-mpm-prefork model, but only with the worker-model ?

55 points by fvbock 15y ago

"A previously unknown flaw in the code for processing byte range headers allows version 2.2.x of the Apache Web Server to be crippled from a single PC." It was pointed out in 2007 http://seclists.org/bugtraq/2007/Jan/83 http://seclists.org/bugtraq/2007/Jan/83 It also affects Apache 1.3.

mwill 15y ago

HN submission for the official advisory: http://news.ycombinator.com/item?id=2924156 http://news.ycombinator.com/item?id=2924156

blantonl 15y ago

are there any haproxy blocking solutions in place yet?

pageman 15y ago
found this: http://www.mail-archive.com/haproxy@formilux.org/msg05625.html http://www.mail-archive.com/haproxy@formilux.org/msg05625.ht... The following regexp works in HAProxy: ([0-9]+-[0-9]+) The same with the coma does not work: ([0-9]+-[0-9]+,) This one works: ([0-9]+-[0-9]+?) And this one does not: ([0-9]+-[0-9]+?)\{10,\}
ominous_prime 15y ago
yes, to quote Willy: What is needed is to remove the Range header when there are too many occurrences of it. Their attack puts up to 1300 Range values. Let's remove the header if there are more than 2 : reqidel ^Range if { hdr_cnt(Range) gt 2 } That should reliably defeat the attack.
- kwantam 15y ago
  It's not just too many occurrences of the header, it's too many ranges specified in a particular header. The zero-day script submits a header that looks like this: Range:bytes=0-,5-1,5-2,5-3,5-4,...,5-1299 I don't know if you were implying something different with your answer since I'm not familiar enough with haproxy to know the semantics of hdr_cnt; I wanted to guard against ambiguity. A simple test of your own machine would be something like this: /bin/echo -en "HEAD / HTTP/1.1\r\nHost:localhost\r\nRange:bytes=0-,$(perl -e 'for ($i=1;$i<1300;$i++) { print "5-$i,"; }')5-1300\r\nAccept-Encoding:gzip\r\nConnection:close\r\n\r\n" | nc localhost 80
  - ominous_prime 15y ago
    Multi-valued headers and multiple headers are interchangeable as long long as the order of values is maintained. Haproxy therefor parses the two into the same internal representation, and the rule works for either.
    - thwarted 15y ago
      This is documented in haproxy's configuration.txt: hdr <string> hdr(header) <string> Note: all the "hdr*" matching criteria either apply to all headers, or to a particular header whose name is passed between parenthesis and without any space. The header name is not case-sensitive. The header matching complies with RFC2616, and treats as separate headers all values delimited by commas. Use the shdr() variant for response headers sent by the server.

toong 15y ago

This doesn't seem to be very effective on my test system (apache2-mpm-prefork 2.2.14-5ubuntu8.4) regarding memory usage triggering the oom-killer. Memory seems to be (almost?) stable, but apache cpu usage is through the roof, with the client barely consuming any cpu. The moment you kill the client, the apache server is back ok. I'll let it run for another hour or so, to see that this actually gets somewhere or not. Are the actual memory increments really small and/or slow ? Or isn't this supposed to work with the apache2-mpm-prefork model, but only with the worker-model ?