Bekijk Volledige Versie : FYI: Apache DoS bug
Apache 1.3 en 2.x hebben een vulnerability waarbij een aanvaller met een beperkt aantal requests de webserver excessief veel CPU en geheugen kan laten gebruiken.
De exploit is bekend en gebruik ervan is gezien.
Patches worden binnenkort (48 uur) verwacht, en workarounds/mitigation is beschreven , samen met verdere details in onderstaande link .
http://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/browser
nog wat leesvoer : http://tweakers.net/nieuws/76368/kwetsbaarheid-maakt-apache-gevoelig-voor-ddos-aanvallen.html
Kreeg daar eerder van de week ook al een e-mailtje over van iemand die security testing wou slijten:
your Server is susceptible to a 0day exploit that I do not call exaclty
because i want to prevent him from spreading further.
There are still no patch for it! The exploit is used to crash the http
daemon and your website goes offline until you restarted the Apache.
The only current solution is to disable the module "mod_gzip" or
"mod_deflate"
in the httpd.conf on your Server!
If u want i can run the exploit then you can see it's true what i say. I
also can run other Security tests for a small fee.
De "beveiligingsexpert" teruggemailt dat het vrij onwaarschijnlijk is dat onze Lighttpd webserver vatbaar was voor Apache fouten... :chinese:
SebastiaanStok
25/08/11, 13:03
mod_deflate uitschakelen :) ja dat lost het probleem op.
Als die "beveiligingsexpert" verder leest ziet hij dat het probleem niet alleen bij mod_deflate speelt maar ook de core van Apache zelf.
Toch raar dat dit al bekent was in 2007 en nu pas iets mee gedaan word.
Ach je hebt altijd nog Slowloris ;)
Toch raar dat dit al bekent was in 2007 en nu pas iets mee gedaan word.
Ach je hebt altijd nog Slowloris ;)Oh, er zitten nog een paar grote security issues in Apache die al jaaaren bekend zijn waar niets mee gedaan wordt.
Wij hebben er hier gelukkig Varnish voor zitten, die vangt dit al mooi af.
Met Apache gaat het soms net zoals met MySQL, sommige bugs zitten er al 5 tot 8 jaar in :) Beetje jammer, dat wel.
Toch jammer dat men het nu pas "oppikt", maar goed, laat die update maar komen.
SebastiaanStok
26/08/11, 12:52
Inmiddels is er meer nieuws beschikbaar.
Het probleem is ook onderdeel van het HTTP protocol zelf, hier wordt momenteel over gediscussieerd.
Volledig bericht.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Apache HTTPD Security ADVISORY
==============================
UPDATE 2
Title: Range header DoS vulnerability Apache HTTPD 1.3/2.x
CVE: CVE-2011-3192
Last Change: 20110826 1030Z
Date: 20110824 1600Z
Product: Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Changes since last update
=========================
In addition to the 'Range' header - the 'Range-Request' header is equally affected. Furthermore various vendor updates, improved regexes (speed and accommodating a different and new attack pattern).
Description:
============
A denial of service vulnerability has been found in the way the multiple overlapping ranges are handled by the Apache HTTPD server:
http://seclists.org/fulldisclosure/2011/Aug/175
An attack tool is circulating in the wild. Active use of this tool has been observed.
The attack can be done remotely and with a modest number of requests can cause very significant memory and CPU usage on the server.
The default Apache HTTPD installation is vulnerable.
There is currently no patch/new version of Apache HTTPD which fixes this vulnerability. This advisory will be updated when a long term fix is available.
A full fix is expected in the next 24 hours.
Background and the 2007 report
==============================
There are two aspects to this vulnerability. One is new, is Apache specific; and resolved with this server side fix. The other issue is fundamentally a protocol design issue dating back to 2007:
http://seclists.org/bugtraq/2007/Jan/83
The contemporary interpretation of the HTTP protocol (currently) requires a server to return multiple (overlapping) ranges; in the order requested. This means that one can request a very large range (e.g. from byte 0- to the end) 100's of times in a single request.
Being able to do so is an issue for (probably all) webservers and currently subject of an IETF discussion to change the protocol:
http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311
This advisory details a problem with how Apache httpd and its so called internal 'bucket brigades' deal with serving such "valid" request. The problem is that currently such requests internally explode into 100's of large fetches, all of which are kept in memory in an inefficient way. This is being addressed in two ways. By making things more efficient. And by weeding out or simplifying requests deemed too unwieldy.
Mitigation:
===========
There are several immediate options to mitigate this issue until a full fix is available. Below examples handle both the 'Range' and the legacy 'Request-Range' with various levels of care.
Note that 'Request-Range' is a legacy name dating back to Netscape Navigator
2-3 and MSIE 3. Depending on your user community - it is likely that you can use option '3' safely for this older 'Request-Range'.
1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
either ignore the Range: header or reject the request.
Option 1: (Apache 2.2)
# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (?:,.*?){5,5} bad-range=1
RequestHeader unset Range env=bad-range
# We always drop Request-Range; as this is a legacy
# dating back to MSIE3 and Netscape 2 and 3.
RequestHeader unset Request-Range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
CustomLog logs/range-CVE-2011-3192.log common env=bad-req-range
Above may not work for all configurations. In particular situations
mod_cache and (language) modules may act before the 'unset'
is executed upon during the 'fixup' phase.
Option 2: (Pre 2.2 and 1.3)
# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteEngine on
RewriteCond %{HTTP:range} !(bytes=[^,]+(,[^,]+){0,4}$|^$)
# RewriteCond %{HTTP:request-range} !(bytes=[^,]+(?:,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
# We always drop Request-Range; as this is a legacy
# dating back to MSIE3 and Netscape 2 and 3.
RequestHeader unset Request-Range
The number 5 is arbitrary. Several 10's should not be an issue and may be
required for sites which for example serve PDFs to very high end eReaders
or use things such complex http based video streaming.
2) Limit the size of the request field to a few hundred bytes. Note that while
this keeps the offending Range header short - it may break other headers;
such as sizeable cookies or security fields.
LimitRequestFieldSize 200
Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.
See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
3) Use mod_headers to completely dis-allow the use of Range headers:
RequestHeader unset Range
Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.
Furthermore to ignore the Netscape Navigator 2-3 and MSIE 3 specific
legacy header - add:
RequestHeader unset Request-Range
Unlike the commonly used 'Range' header - dropping the 'Request-Range'
is not likely to affect many clients.
4) Deploy a Range header count module as a temporary stopgap measure:
http://people.apache.org/~dirkx/mod_rangecnt.c
Precompiled binaries for some platforms are available at:
http://people.apache.org/~dirkx/BINARIES.txt
5) Apply any of the current patches under discussion - such as:
http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3cCAAPSnn2PO-d-C4nQt_TES2RRWiZr7urefhTKPWBC1b+K1Dqc7g@mail.gmail. com%3e
http://svn.apache.org/viewvc?view=revision&sortby=date&revision=1161534
OS and Vendor specific information
==================================
Red Hat: Option 1 cannot be used on Red Hat Enterprise Linux 4.
https://bugzilla.redhat.com/show_bug.cgi?id=732928
NetWare: Pre compiled binaries available.
mod_security: Has updated their rule set; see
http://blog.spiderlabs.com/2011/08/mitigation-of-apache-range-header-dos-attack.html
Actions:
========
Apache HTTPD users who are concerned about a DoS attack against their server should consider implementing any of the above mitigations immediately.
When using a third party attack tool to verify vulnerability - note that most of the versions in the wild currently check for the presence of mod_deflate; and will (mis)report that your server is not vulnerable if this module is not present. This vulnerability is not dependent on presence or absence of that module.
Planning:
=========
This advisory will be updated when new information, a patch or a new release is available. A patch or new Apache release for Apache 2.0 and 2.2 is expected in the next 24 hours. Note that, while popular, Apache 1.3 is deprecated.
- -- end of advisory - update 2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
iEYEARECAAYFAk5Xdu8ACgkQ/W+IxiHQpxvN8ACgwsUJ6oYMq3SyoPHCR7rqsbP6
DFkAoKhZcF87F96h40tQdM1SZsiVX9N5
=07sc
-----END PGP SIGNATURE-----
Tot op heden nog geen update te zien? Als ik de test uitvoer op mijn eigen server krijg ik de melding dat mijn server niet vatbaar is.. Terwijl ik niks heb gedaan, blijkbaar werkt het niet op 'alle' apache servers? Draai overigens gewoon 2.2.19
dit ook gezien/gechecked?
When using a third party attack tool to verify vulnerability - note that most of the versions in the wild currently check for the presence of mod_deflate; and will (mis)report that your server is not vulnerable if this module is not present. This vulnerability is not dependent on presence or absence of that module.
Ik heb die killapache.pl eens aangepast en die check gewoon eruit gegooit
En run hem nu maar eens op een eigen test server en zie wat er gebeurt.
En inmiddels is er een fix.
https://www.apache.org/dist/httpd/Announcement2.2.html
Beetje laat om te melden, maar DA heeft inmiddels ook een mailing uitgestuurd.
Straks maar eens
./build update
./build apache
doen.
SebastiaanStok
03/09/11, 09:30
Hoezo? Als de Apache hoofdversie onveranderd is hoef je de modules niet opnieuw te compileren :)
John raadt aan altijd ./build php n te doen na een update van apache, het zekere voor het onzekere. Kleine moeite en voorkomt dat je eventueel door het overslaan toch tegen problemen aanloopt.
Hij heeft uitgelegd dat het anders misschien voor segfaults kan zorgen, las ik.