Bug 761327
Summary: | Remote Denial Of Service with Unknow binary compiled by "ev1lut10n" | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | xset1980 | ||||
Component: | httpd | Assignee: | Joe Orton <jorton> | ||||
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 16 | CC: | jkaluza, jorton, maurizio.antillon, pahan, rcvalle, roomojee, security-response-team, ville, wnefal+redhatbugzilla | ||||
Target Milestone: | --- | Keywords: | Reopened, Security | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 765979 (view as bug list) | Environment: | |||||
Last Closed: | 2012-06-06 16:08:14 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
xset1980
2011-12-08 03:50:42 UTC
Created attachment 542354 [details]
exploit and access_log file into .tar.gz
http://myw1sd0m.blogspot.com/2011/09/remote-apache-denial-of-service-exploit.html http://jayakonstruksi.com/backupintsec/rapache.tgz Remote Apache Denial of Service Exploit | coded by ev1lut10n Download url : http://jayakonstruksi.com/backupintsec/rapache.tgz bug found by : Nikolaus Rango (Kingcope) sploit coded by : ev1lut10n evllut10n's email : ev1lut10n_exploit ev1lut10n's gopher : gopher://sdf.org/1/users/ev1lut10 thanks to: X-hack, Danzel, superman,flyff666,peneter,wenkhairu, fadli,gunslinger,petimati,net_spy, and all my friends and you ! ================= root@ev1l:/home/ev1lut10n# ./rapache Remote Apache Denial of Service Exploit by ev1lut10n [-] Usage : ./rapache hostname root@ev1l:/home/ev1lut10n# =================== =========== affected: Apache HTTP Server 1.3.x, 2.0.x through 2.0.64, and 2.2.x through 2.2.19 ============== Diposkan oleh mywisdom di 10:55 Kirimkan Ini lewat Email BlogThis! Berbagi ke Twitter Berbagi ke Facebook Making this public, as your other bug, as well as your references, are already public. (In reply to comment #3) > Making this public, as your other bug, as well as your references, are already > public. Ok, no problem, but, i did not know that _this_ particular exploit, modified by ev1lut10n, was public and was being used, since by looking at the creation date, i supposed it was already fixed. Besides that, I did not saw it reported, wich caught my attention, added to the fact that on Freenode's IRC, either in support and social channels for Fedora, they did not pay attention to it, arguing it was my issue, and that in Fedora this didn't occur. So, is because of this i assumed that it wasn't public, and I followed the guide, wich indicated, that if it was a security issue should be mark as private. Anyway, you should know better about this than me, so from my side, the task of making a PoC, has already been done. Regards, Sp0ck -irc.freenode.net- I opted to make this public as the RHEL version of this bug (bug #761312) had the same details and was public, but also because we've already spent time looking into this and have no reason to believe there is a problem with the current fix for the CVE-2011-3192 issue. More information should appear here soon. Thank you for bringing this to our attention. @Tomas Hoger Ok, is true, and good for me. The old code in perl of Kingcope is solved with the actual fix (updates), but the new code of rapache no cause the same impact, no high cpu usage and memory, only freeze the httpd server, and the actual versions, fixed, are vulnerable too, the only change that i see is the range, 0-100 replaced by 0-,0-, anyway, i think that depend of Apache Foundation. Other thing!, the actual mitigation method, no work :( Regards. sp0ck *** Bug 761312 has been marked as a duplicate of this bug. *** The mentioned rapache binary is not related to CVE-2011-3192 and Kingcope's killapache.pl and is not a modified / improved variant of it. It does sent a suspiciously-looking Range header with value "0-,0-", but the header is never processed. This is because rapache does not send a valid HTTP request, what is sent lacks proper terminating blank line. Therefore, httpd never sees complete request and eventually times out and drops connection that only provided invalid request. It is unclear, if the Range header is used as disguise, or the intention was to exploit CVE-2011-3192, but it wasn't coded properly. This program starts new threads and opens new connections to target server without any limit. Therefore, if no other protection is in place, it quickly exhausts httpd's connection limit (you should see an error about MaxClients being reached), which blocks connections from other clients. This is no novel attack, but a problem that affects any network-facing service and can be mitigated by e.g. enforcing connection limit per IP. I haven't analysed this. However, my guess is that this could be the result of the httpd processing the combination of an invalid "Range" header with an "Accept-Encoding: gzip" within a malformed or non finished HEAD HTTP/1.1 request. @Tomas Hoger Aha, and what is the mitigation mode?, because is the same effect in NGINX and Apache running in Windows XP, so, how fix it in my server?. @Tomas Hoger Mmm... I'm normal user without any militar computer installation or NASA cluster, or use Cisco product related. I'm normal an user that ask, why occurs this?, If I used Windows with Apache and occurs too. So, this is independent of operative system I use, Linux, OpenBSD, NetBSD on all. However, I try to take down a IIS without successful. IIS resists this "attacks". Why happens this? Too, If you can see the log I added that Apache make auto-petition and source code of this script see make a localhost HEAD petition. In addition to, I tried to see that Apache did it, with netcat and I could see it. So, Apache and other server "believe" this/these petition and attend it. Not only is distress about MaxClients, if not try to attend auto-petitions, but this "dummy" registered on Apache log. As noted above, you can protect by limiting the number of connections per IP. You can do that using e.g. iptables connlimit (see example in e.g. bug #508238, comment #2). You can find few tips in httpd docs: http://httpd.apache.org/docs/trunk/misc/security_tips.html#dos and some discussion of the similar attack concept: https://lwn.net/Articles/338407/ *** Bug 765979 has been marked as a duplicate of this bug. *** ev1lut10n source, with few tweaks since the original version: http://packetstormsecurity.org/files/107923/rapache2.c This version too has a problem of sending an incomplete header, as was noted in comment #11. @Tomas Hoger Yes, limiting the number of connections per IP the trouble is solved, _but_, NGINX, Cherokee are not vulnerable (not freeze the web server, only aumented the forker process in CPU usage), but both respond ever. Apache httpd most efficient "fix", without using iptables, is: Timeout 3 KeepAlive Off MaxKeepAliveRequest 0 KeepAliveTimeout 10 With this settings in httpd.conf is parcially solved, the apache 2.2.21 and 2.2.15 freezes 3 seconds with rapache attack and after attack, work fine, but NGINX and cherokee with default configuration, they ignore the bad request of rapache or rapache2 exploit, so, is not a bug and is *a bad code of apache* or is a little bug?.- Regards. Being able to hit configured (or default) connection limits is not a bug, it is inevitable. Everything else is explained by the links provided by Tomas above. |