lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 13 Sep 2011 12:26:58 +1000
From: xD 0x41 <secn3t@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Apache Killer

I know this topic is OLD but, i just wonder and, also having spoken to kcope
re this myself, discussed the size of each bucket wich can be made to
stupendous amounts and using a different vector, ok, instead of Range:bytes=
, picture a GET request with as was shown in the code is there, you
"Request-Range: bytes=5-,5-69,5-" , now we have bypassed most filters
already in place, and the request range code, is exactly the same as range
code.
Only one person spotted this.

Anyhow, This started about byte= 'stupendous' amount but, in the end there
is a few ways that people are still using this..
remember it does not need any mod_deflate or mod_gzip to function... i have
not tested the method outlined on anything new, but it was pretty nasty on
the old systems wich is now made worse if you set the byterange to a high
amount from start, rather than sending 0- first... you can just avoid it and
stay in the middle and lower it, but the problem can be repeated in some
packages, and im retesting using a simple bit of code called create_conns.c
and modified GET request.
create_conns code is googleable, just google for create_conns.c by n0ah and
you have found that app...  you can even try a slowloris app and just send
one packet. Simple enough to recreate this.. as this is not about 'range'
anymore.

Also i found this bypasses the filters set by mod_filter wich were
'suggested' and actually added to part of the fix, or some fix's were based
on this.. i think that maybe a time to look at some modified code of this,
or just setup better traps, better yet, use a patched package, as i do not
*think* these are affected, but dont use any of the quick-fixes is what is
to be learnt from this exploit in a BIG way.
on FreeBSD the httpd on v8.0 was affected so badly, i have never seen a
httpd die so badly, as with a flavor of citrix wich was interesting. Anyhow
moving on...

Anyhow, i know it is old but, i am seeing people still with this problem,
who dont realise that some quick-patches, is NOT the way togo...
I would assume apache have seen that request-Range exists in the same LINE
as range code, does wich is affected, so they would be abit crazy to NOT
patch that.
I do remember one person showing the affected line in wich request-range
was, and i looked it up in my code and bingo, it was same as his example so
i assume request-range would be used in a request form.
A system GET or POST perhaps... anyhow regardless, i just thought of this
and the discussions ive had re this, and think it should be checked 1000% :P
Sorry for those who it annoys but, im a fussy fofo on that side of things,
ie httpd/ftpd MUST be spankin perfect or i dont rest.
Thanks for those who originally and still, help on this topic.
Always, thx to kcope for atleast releasing it so it could be patched. <3
and ofcourse, always my buddies on #haxnet@ef, who help me with these
discussions.
Dos sucks, but hiding from it sucks worse.
cheers to all, and specially for those affected by 9/11,my special regards.
xd / dru

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ