[Full-disclosure] CVE-2013-4425: Private key disclosure, Osirix (lite, 64bit and FDA cleader version) (Medical Application)
requirements for (good) manufacturing
practices. Therefore this mitigation may not fully resolve the issues
when judged against normal industry best practices and/or regulatory
requirements for private key handling in certain countries.
This because the applied mitigation does still require the extraction
of a private key to process memory; as opposed to making use of the
normal OSX cryptographic primitives within a hardware/soft-token
security sandbox. And it does expose the password of the keyfile as a
command line argument (which is hard coded to the OS its own OpenSSL
binary; which is well protected), albeit very very shortly.
Timeline and disclosure:
2013-10-15 Issue confirmed, CVE issued, issue reported to vendor.
2013-10-16 Vendor response; will push out a fix as part of a
planned release by/around mid December 2013.
2013-11-02 Vendor released 5.8, 2.8-MD
2013-11-06 First disclosure, version 1.09
Bibliographic References and classification:
===
@techreport{CVE-2013-4425,
Number = {CVE-2013-4425},
Title = {Private key disclosure, Osirix (lite, 64bit and FDA cleader
version)},
Author = {Dirk-Willem van Gulik},
Institution = {WebWeaving.org},
Month = {11}, Year = {2013},
Type = {Vulnerability Report, Responsible Full Disclosure},
Address = {Janvossensteeg 37, 2312WC, Leiden, Netherlands}
}
CVSSv2: AV:L/AC:L/Au:N/C:C/I:N/A:P/E:H/RL:U/RC:C/CDP:H/TD:H
CVSS Base Score 7.2
Impact Subscore 10.0
Exploitability Subscore 3.9
CVSS Temporal Score 6.8
CVSS Environmental Score 8.4
Modified Impact Subscore 10.0
Overall CVSS Score 8.4
Credits:
Dirk-Willem van Gulik (dirkx (at) webweaving (dot) org) as part of the
Artemis/EU project HighProfile (http://www.highprofile-project.eu/).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: This message is encrypted and/or signed with PGP (gnu-pg, gpg).
Contact di...@webweaving.org if you cannot read it.
iQCVAwUBUnpH2TGmPZbsFAuBAQKpjQP/V+pNz+Voh4lBglSO0QxYyHJEHQaloMyS
nwY3+ASclKaztCjxC6RKgCSvdtFTqxABeRVs7edhmdbAIRDevXC+4mYwXb6cVWbX
jKZ6jBrXoa1rhjJjnBhw919J+PlYsyazgTyY/4yXPHKlOnBaVFt5L2LiQB/cS747
M6YlYpunJQI=
=7jdT
-END PGP SIGNATURE-
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] CVE-2013-186y: tokend (Apple, Gemalto) - privacy leak arbitrary file creation (OSX, All versions)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSC.tokend (1,2) is a Tokend module for OS X CDSA/Keychain subsystem for accessing smart cards. As is common in such bridges to a relatively slow medium (chipcards in readers on serial/USB); tokend relies on a cache. This cache is kept in /var/db/TokenCache. This directory is root owned and its content only readable by root. It contains directories on a per chipcard, per token basis. The name for this directory is constructed using the label of the card, its serial number and the label of the token. These can contain arbitrary UTF8 strings up to 255 bytes long when exposed directly through OpenSC.tokend (PKCS#15) its module as picked up by the the securityd. (There is a related issue with OpenSC its pkcs#11 driver via Gemalto/Apple's tokend plugin and then onto securityd; See CVE-2013-1867) This makes it possible for an attacker to construct card labels or token labels that may cause the overwriting (by a root process) of somewhat arbitrary directories (and in some cases files) on the file system (somewhat limited by a length constraint on the card and token-label) upon insertion. Symbolic links are followed without ado. As tokend generally runs at all time - such insertion can be done even when the user is logged out or the screen locked. CVE: CVE-2013-1866 Impact: - --- 1) An attacker with physical access to a reader can create/corrupt a wide range of directories on the file system. 2) An attacker with physical access to a legitimate smart card (holder) can substitute/reprogram an existing card to do such when the legitimate holder inserts the doctored card at some later point[5]. 3) As errors are logged to a public-readable log file - some information about which token was inserted at what time leaks inadvertently. This has issues in certain setting[7]. Such leakage can also be 'caused' by making the cache directory or disk in-accessible/full. 4) In certain (possibly common) circumstances the attacker can cause one card to (re)use the cache of another card[6]. 5) The attack can be executed with an existing chipcard, already in use within the organisation; or with virtually any other chipcard (including blank unprogrammed chipcards) provided that at least one of the token plugins is able to read the card. 6) Above also applies to so called 'USB Token's; which are technically chipcards hardwired (or in the form of a small physical form factor SIM card) into a reader in a convenient USB thumb-drive style enclosure. Versions affected: - -- 1) All builds prior to 15th of March 2013; all versions of OSX. On affected systems syslog will generally show entries such as com.apple.SecurityServer[829]: reader RRR inserted token XX (XXX) subservice DD using driver com.apple.tokend.opensc where XXX is a label on the chipcard. A failed exploit attempt will appear as OpenSC[PID]: error writing cache file: /var/db/TokenCache/... follewed by errors such as 'Permission denied' or 'No such file or directory'. Note that a perfectly executed exploit will not leave such traces. Solution: - - The 0.13.0 build of 2013-03-19 (or later): https://www.opensc-project.org/downloads/macosx/ includes a full and complete fix. Mitigation: - --- 1) Limit physical access; make personnel aware of the risks of inserting a 'rogue' card or loosing control of a card temporarily and using it subsequently. Note however that most installations allow the reprogamming of an already inserted card its (outer) label without root access. 2) Manually upgrade to a version of OpenSC.tokend later than commit: c013f819104280eac758d15a57d1aa4848c35654. 3) Update using the attached patches. 4) Consider pruning the installed security agent bundles to an absolute minimum. Note that (as some proprietary vendors may suggest) that removing the OpenSC #15 based plugin and relying on the Gemalto/Apple PKCS#11 'tokend' bridge into securityd instead is subject to a similar issue as described in CVE-2013-1867. Note that (as some proprietary vendors may suggest) removing the OpenSC plugins and PKCS#11 libs and switching to a different vendor is also subject to the issue described in CVE-2013-1867 (as it happens one layer 'higher'). Likewise even though an existing installation may not use tokend or may use a vendors plugin that filters/curtails the label - the insertion of a different brand of card may still be used to bypass that specific vendor's protection when it gets picked up by a (previously possibly dormant) plugin. Long term solution - -- 1) Upgrade OpenSC.tokend to a release post March 2013. Timeline Credits: - --- Discovered by Dirk-Willem van Gulik (di...@webweaving.org) as part of the Artemis/EU project HighProfile. Fix applied to the release branch by Martin Paljak. Footnotes: - -- 1: https://www.opensc-project.org/opensc/wiki
[Full-disclosure] CVE-2013-1866: OpenSC.tokend - privacy leak arbitrary file creation (OSX, All versions)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSC.tokend (1,2) is a Tokend module for OS X CDSA/Keychain subsystem for accessing smart cards. As is common in such bridges to a relatively slow medium (chipcards in readers on serial/USB); tokend relies on a cache. This cache is kept in /var/db/TokenCache. This directory is root owned and its content only readable by root. It contains directories on a per chipcard, per token basis. The name for this directory is constructed using the label of the card, its serial number and the label of the token. These can contain arbitrary UTF8 strings up to 255 bytes long when exposed directly through OpenSC.tokend (PKCS#15) its module as picked up by the the securityd. (There is a related issue with OpenSC its pkcs#11 driver via Gemalto/Apple's tokend plugin and then onto securityd; See CVE-2013-1867) This makes it possible for an attacker to construct card labels or token labels that may cause the overwriting (by a root process) of somewhat arbitrary directories (and in some cases files) on the file system (somewhat limited by a length constraint on the card and token-label) upon insertion. Symbolic links are followed without ado. As tokend generally runs at all time - such insertion can be done even when the user is logged out or the screen locked. CVE: CVE-2013-1866 Impact: - --- 1) An attacker with physical access to a reader can create/corrupt a wide range of directories on the file system. 2) An attacker with physical access to a legitimate smart card (holder) can substitute/reprogram an existing card to do such when the legitimate holder inserts the doctored card at some later point[5]. 3) As errors are logged to a public-readable log file - some information about which token was inserted at what time leaks inadvertently. This has issues in certain setting[7]. Such leakage can also be 'caused' by making the cache directory or disk in-accessible/full. 4) In certain (possibly common) circumstances the attacker can cause one card to (re)use the cache of another card[6]. 5) The attack can be executed with an existing chipcard, already in use within the organisation; or with virtually any other chipcard (including blank unprogrammed chipcards) provided that at least one of the token plugins is able to read the card. 6) Above also applies to so called 'USB Token's; which are technically chipcards hardwired (or in the form of a small physical form factor SIM card) into a reader in a convenient USB thumb-drive style enclosure. Versions affected: - -- 1) All builds prior to 15th of March 2013; all versions of OSX. On affected systems syslog will generally show entries such as com.apple.SecurityServer[829]: reader RRR inserted token XX (XXX) subservice DD using driver com.apple.tokend.opensc where XXX is a label on the chipcard. A failed exploit attempt will appear as OpenSC[PID]: error writing cache file: /var/db/TokenCache/... follewed by errors such as 'Permission denied' or 'No such file or directory'. Note that a perfectly executed exploit will not leave such traces. Solution: - - The 0.13.0 build of 2013-03-19 (or later): https://www.opensc-project.org/downloads/macosx/ includes a full and complete fix. Mitigation: - --- 1) Limit physical access; make personnel aware of the risks of inserting a 'rogue' card or loosing control of a card temporarily and using it subsequently. Note however that most installations allow the reprogamming of an already inserted card its (outer) label without root access. 2) Manually upgrade to a version of OpenSC.tokend later than commit: c013f819104280eac758d15a57d1aa4848c35654. 3) Update using the attached patches. 4) Consider pruning the installed security agent bundles to an absolute minimum. Note that (as some proprietary vendors may suggest) that removing the OpenSC #15 based plugin and relying on the Gemalto/Apple PKCS#11 'tokend' bridge into securityd instead is subject to a similar issue as described in CVE-2013-1867. Note that (as some proprietary vendors may suggest) removing the OpenSC plugins and PKCS#11 libs and switching to a different vendor is also subject to the issue described in CVE-2013-1867 (as it happens one layer 'higher'). Likewise even though an existing installation may not use tokend or may use a vendors plugin that filters/curtails the label - the insertion of a different brand of card may still be used to bypass that specific vendor's protection when it gets picked up by a (previously possibly dormant) plugin. Long term solution - -- 1) Upgrade OpenSC.tokend to a release post March 2013. Timeline Credits: - --- Discovered by Dirk-Willem van Gulik (di...@webweaving.org) as part of the Artemis/EU project HighProfile. Fix applied to the release branch by Martin Paljak. Footnotes: - -- 1: https://www.opensc-project.org/opensc/wiki
[Full-disclosure] CVE-2013-1867: tokend (Apple, Gemalto) - privacy leak arbitrary file creation (OSX, All versions)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tokend is a module for OS X CDSA/Keychain subsystem for accessing smart cards. It acts as a bridge between the apple KeyChain and PKCS#11 libraries for smartcards, hardware security modules, cryptographic accelerators and various other security devices. It shipped with OSX up until and including 10.6[1]. It is also known as the Gemalto Tokend. It is no longer part of the base install from 10.7 (Lion) onwards. However an open source version lives on[2]. This version is commonly installed in enterprise installations, research and defence; often in conjunction with OpenSC[3]. OpenSC or derivatives may also come bundled as part of a SSO installation or with chipcard-readers their drivers. As is common in such bridges to a relatively slow medium (chipcards in readers on serial/USB); tokend relies on a cache. This cache is kept in /var/db/TokenCache. This directory is root owned and its content only readable by root. It contains directories on a per token basis. The name for this directory is constructed using the label and the serial number. These can contain arbitrary UTF8 strings up to 64 and 32 bytes long[4]. This makes it possible for an attacker to construct token labels that may cause the overwriting (by a root process) of somewhat arbitrary directories (and in some cases files) on the file system (somewhat limited by a length constraint on the token-label) upon insertion. Symbolic links are followed without ado. As tokend generally runs at all time - such insertion can be done even when the user is logged out or the screen locked. CVE: CVE-2013-1867 Impact - -- 1) An attacker with physical access to a reader can create/corrupt a wide range of directories on the file system. 2) An attacker with physical access to a legitimate smart card (holder) can substitute/reprogram an existing card to do such when the legitimate holder inserts the doctored card at some later point[6]. 3) As errors are logged to a public-readable log file - some information about which token was inserted at what time leaks inadvertently. This has issues in certain setting[7]. Such leakage can also be 'caused' by making the cache directory or disk in-accessible/full. 4) In certain (possibly common) circumstances the attacker can cause one card to (re)use the cache of another card[7]. 5) The attack can be executed with an existing chipcard, already in use within the organisation; or with virtually any other chipcard (including blank unprogrammed chipcards) provided that at least one of the token plugins is able to read the card. 6) Above also applies to so called 'USB Token's; which are technically chipcards hardwired (or in the form of a small physical form factor SIM card) into a reader in a convenient USB thumb-drive style enclosure. Versions affected - - All builds of tokend where installed build from the open source repository as of March 2013. TokenD is installed on OSX 10.6 and older by default. Various chipcard and security products install a version of it as part of their driver suite. PKCS#11 distributions of a wide range of vendors are known to allow such labels. A telltale sign of this type of use is entries in syslog matching: com.apple.SecurityServer[22]: reader XXX inserted token RR (XXX) subservice DD using driver com.gemalto.tokend where XXX are the labels on the chipcard. Failed exploits may show up as (with XXX the name of the bundle): XXX [41975]: error writing cache file: /var/db/TokenCache/ followed by errors such as 'No such file or directory', 'Permission denied' etc. A well executed exploit will not leave such traces. Even though an existing installation may not use tokend or may use a plugin that filters/curtails the label - the insertion of a different brand of label may still be used to bypass that specific vendor's protection. Mitigation - -- 1) Limit physical access; make personnel aware of the risks of inserting a 'rogue' card or loosing control of a card temporarily and using it subsequently. Note however that most installations allow the reprogamming of an already inserted card its (outer) label without root access. 2) Apply the attached patch. 3) Consider pruning the installed security agent bundles and PKCS#11 bundles to an absolute minimum. Long term Solution - -- There is currently no vendor support for tokend - and we've not been able to find a maintaineri. Not did we any reaction from the author (Gemalto N.V. HQ is unable to find a security officer) or its current publisher (Apple)). Timeline Credits - -- Discovered by Dirk-Willem van Gulik (di...@webweaving.org) as part of the Artemis/EU project HighProfile. Fix below in consultation with Martin Paljak of OpenSC. Bootnote - Note that this opensource tokend[2] package is a common (and pretty much the only known) basis for third party/proprietary vendors to base
[Full-disclosure] Advisory: Range header DoS vulnerability Apache HTTPD 1.3/2.x (CVE-2011-3192)
-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)
Re: [Full-disclosure] Advisory: Range header DoS vulnerability Apache HTTPD 1.3/2.x (CVE-2011-3192)
On 26 Aug 2011, at 12:09, Carlos Alberto Lopez Perez wrote:
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC,OR]
RewriteCond %{HTTP:request-range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC]
RewriteRule .* - [F]
Because if you don't specify the [OR] apache will combine the rules
making an AND (and you don't want this!).
Also use NC=(nocase) to prevent the attacker upper casing bytes=
(don't know if it will work.. but just to prevent)
Thank you - will double check add in next/final advisory.
Dw.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Advisory: Range header DoS vulnerability Apache HTTPD 1.3/2.x (CVE-2011-3192)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Apache HTTPD Security ADVISORY
==
UPDATE 1
Title: Range header DoS vulnerability Apache HTTPD 1.3/2.x
CVE: CVE-2011-3192
Last Change: 20110824 1800Z
Date:20110824 1600Z
Product: Apache HTTPD Web Server
Versions:Apache 1.3 all versions, Apache 2 all versions
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 tools 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 48 hours.
Mitigation:
There are several immediate options to mitigate this issue until a full fix
is available:
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.0 and 2.2)
# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
Option 2: (Also for Apache 1.3)
# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
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.
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+k1dq...@mail.gmail.com%3e
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.
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 - know 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 48 hours. Note that, while popular, Apache 1.3 is deprecated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)
iEYEARECAAYFAk5VLSEACgkQ/W+IxiHQpxt1nwCdGr9RY3zH1poh05wX8MagEp9z
qhMAoLKdnTzY+tJVdce8312WTzaEZ9Yo
=VeWb
-END PGP SIGNATURE-
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apache Killer
On 25 Aug 2011, at 05:54, Michal Zalewski wrote: just for the record I have the impression that this not the same vulnerability you outlined in your advisory a while back. It is more that the idea for this vulnerability originated from your advisory, not the same bug. I don't think this even matters, and I really don't disagree... In 2007, I noticed that their Range handling is silly, and may prompt them to generate very large responses. Hmm - I think we are conflating two issues: 1) The contemporary interpretation of RFC 2616 allows for multiple overlapping ranges; requires them to be returned in order and has easy ways (e.g. 0-) of asking for a lot of data. This basically means that a small request can cause the server to prep a lot of data and, assuming the TCP connection looks alive to the server; lots of data to be sent out. And because Ranges are fundamentally about arbitrary ranges - this means hard work for the server. This is an issue for all web servers implementing Range according to RFC2616 properly. This strict interpretation is currently discussed in the IETF: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311 This issue is, a Michal's 2007 email importantly points out, cross server. Not just Apache. And I am sure we've not heard the last of this. Then there something very apache 1.3/2.0/2.2 specific 2) Under certain (very common) conditions Apache internally is really rather inefficient at handling such request which 'explode' into many 100's of internal requests for large byte ranges. This is purely due to how it sets up the various bucket brigades and a lingering/remnant of the good old 0.9 times where one request meant one file and one reply. The latter needs to be fixed in the apache code - and it would not surprise me if we'll see more issues like this; where design assumptions from the old 1:1:1 times are no longer valid. Thanks, Dw. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
