Re: [OT] Re: Apache Web Server vulnerability
At 20:06 21.06.2002, Philip Mak wrote: >On Fri, Jun 21, 2002 at 05:31:00AM -0700, Ask Bjoern Hansen wrote: > > 64bit binaries are exploitable. There are also exploits for several > > 32bit systems. > >Does anyone know if Red Hat Linux 7.2 on i686 is vulnerable to the >remote shell (not the DoS) exploit? I suggest bringing this up on the appropriate httpd lists instead. This thread has gone far enough IMO. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: [OT] Re: Apache Web Server vulnerability
> On Fri, 21 Jun 2002 14:06:45 -0400, Philip Mak <[EMAIL PROTECTED]> said: PM> On Fri, Jun 21, 2002 at 05:31:00AM -0700, Ask Bjoern Hansen wrote: >> 64bit binaries are exploitable. There are also exploits for several >> 32bit systems. PM> Does anyone know if Red Hat Linux 7.2 on i686 is vulnerable to the PM> remote shell (not the DoS) exploit? Very likely. While most advisories claimed that it is imposible to exploit it on 32bit architectures later there was posted working exploit for x86 port of OpenBSD. Author of exploit claimed that he have been able to exploit Linux, FreeBSD and Solaris too. Though exploits for these platforms have not been published (yet). -- Ilya Martynov (http://martynov.org/)
[OT] Re: Apache Web Server vulnerability
On Fri, Jun 21, 2002 at 05:31:00AM -0700, Ask Bjoern Hansen wrote: > 64bit binaries are exploitable. There are also exploits for several > 32bit systems. Does anyone know if Red Hat Linux 7.2 on i686 is vulnerable to the remote shell (not the DoS) exploit?
Apache Web Server vulnerability the full monte
June 21, 2002 High Risk Apache Exploit Circulating By Ryan Naraine The Apache Foundation has issued a warning that exploits to its chunk handling vulnerability are circulating on the Internet, putting users of its open-source server at high risk. The vulnerability, which Apache now says affects both 64-bit platforms and 32-bit platforms alike, could cause denial-of-service attacks or allow a attacker to take remote control of a server. "Though we previously reported that 32-bit platforms were not remotely exploitable, it has since been proven (that certain conditions allowing exploitation do exist)," Apache warned, urging users upgrade to versions 1.3.26 and 2.0.39 to apply a comprehensive fix. "Due to the existence of exploits circulating in the wild for some platforms, the risk is considered high...All users are urged to upgrade immediately," the Foundation said. Apache updated its security bulletin to warn that exploitation of the chunk handling bug could lead to 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," Apache said, referring to a patch that was issued by the Internet Security Systems (IIS) that did not offer a comprehensive fix. The existence of the Apache exploit made the rounds on the popular Bugtraq security e-mail list. Posts to the list include this warning that the Apache exploit tool was "./friendly," meaning anyone with basic scripting capabilities "should be able to run it without any trouble." The release of the source code for the Apache exploit adds new fuel to the controversy over how the bug announcement was handled. The original warning was first reported by the ISS, causing friction between the security outfit and the Apache Foundation. Apache officials were upset they weren't first notified before the ISS issued its advisory and patch, a normal procedure when bugs are detected. The Apache Foundation said the bug affected versions of its Web server up to and including 1.3.24 and 2.0 up to and including 2.0.36 and 2.0.36-dev, warning that it could be triggered remotely by sending a carefully crafted invalid request, which 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," Apache said. Because Apache servers on the Windows and Netware platforms runs one multithreaded child process to service requests, the Foundation said 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," it explained. In the Apache 2.0 version, it said the error condition is correctly detected and would not allow an attacker to execute code on the server. In Apache 1.3, it said the issue causes a stack overflow. The Foundation again warned that vendor patches should be used to correct the vulnerability as a matter of urgency. http://www.apache.org/dist/httpd/Announcement.html Since I do not use mod_proxy anyone know why the default is not minimalistic adding just enough functionality as req? Seems to me enabling rather than disabling is better. TIA This is now way OT AFAIK. Best Regards, [EMAIL PROTECTED] -- /* Security is a work in progress - dreamwvr */ # # Note: To begin Journey type man afterboot,man help,man hier[.] # // "Who's Afraid of Schrodinger's Cat?" /var/(.)?mail/me \? ;-]
Re: Apache Web Server vulnerability
On Fri, Jun 21, 2002 at 05:31:00AM -0700, Ask Bjoern Hansen wrote: > On Wed, 19 Jun 2002, dreamwvr wrote: > > > "my comments FWIW" > > This means thus far does not impact as_seriously little endian NIX > > based architectures. The reason being? That Apache spawns a pool of > > child processes to serve requests. Therefore a DoS kills the child serving > [...] > > This doesn't make much sense at all. To elaborate this opinion was based on the conclusions of one of the advisories .. > 64bit binaries are exploitable. There are also exploits for several > 32bit systems. well I did not say that x86 was not exploitable. However nix based archs were more difficult. This due to spawning ps rather than as windows and novell using a single process and many threads. That was directly from an advisory.. actually. && in reference to the SEGVs .. directly. > If done "right" these will give the attacker shell access to the > server. Your comments about threaded vs "multi processed" are only > relevant when the exploit is not "done right" (when the server > SEGVs). True; ( && that is what exactly I was referring to.. :) well any exploit "if_done_right" can expand into a full blown remote exploit for example. Once someone is local then basically it is only a matter of time. IMHO. OR if you like sooner or later. Best Regards, [EMAIL PROTECTED] -- /* Security is a work in progress - dreamwvr */ # # Note: To begin Journey type man afterboot,man help,man hier[.] # // "Who's Afraid of Schrodinger's Cat?" /var/(.)?mail/me \? ;-]
Re: Apache Web Server vulnerability
On Fri, 21 Jun 2002, Ask Bjoern Hansen wrote: > On Thu, 20 Jun 2002, Lupe Christoph wrote: > > [...] > > Sorry that is not the answer to my question - the question is if my > > code gets a chance to do *anything*, or will the httpd code just > > crash at a later time? It does not crash like a non-mod_perl httpd. > > I believe it only crashes when using the default handler. Don't > count on it though; there is plenty of obscure ways this issues has > been biting us already. I think not only default handler. If you return 404 or some another error and keepalive is enabled then Apache calls ap_discard_request_body() and start to read chunked body. Second way is to send wrong 'Expect' header - Apache again calls ap_discard_request_body(). Igor Sysoev http://sysoev.ru
Re: Apache Web Server vulnerability
On Wed, 19 Jun 2002, dreamwvr wrote: > "my comments FWIW" > This means thus far does not impact as_seriously little endian NIX > based architectures. The reason being? That Apache spawns a pool of > child processes to serve requests. Therefore a DoS kills the child serving [...] This doesn't make much sense at all. 64bit binaries are exploitable. There are also exploits for several 32bit systems. If done "right" these will give the attacker shell access to the server. Your comments about threaded vs "multi processed" are only relevant when the exploit is not "done right" (when the server SEGVs). - ask -- ask bjoern hansen, http://askbjoernhansen.com/ !try; do();
Re: Apache Web Server vulnerability
On Thu, 20 Jun 2002, Lupe Christoph wrote: [...] > Sorry that is not the answer to my question - the question is if my > code gets a chance to do *anything*, or will the httpd code just > crash at a later time? It does not crash like a non-mod_perl httpd. I believe it only crashes when using the default handler. Don't count on it though; there is plenty of obscure ways this issues has been biting us already. - ask -- ask bjoern hansen, http://askbjoernhansen.com/ !try; do();
Re: Apache Web Server vulnerability
On Fri, 21 Jun 2002, Richard [utf-8] Čepas wrote: > On Wed Jun 19 17:54:02 2002 +0400 Igor Sysoev wrote: > > >On 19 Jun 2002, Ilya Martynov wrote: > > > >> If you still do not know about it: > >> > >> http://httpd.apache.org/info/security_bulletin_20020617.txt > >> > >> Now mod_perl question. mod_perl servers often are used as backend > >> servers. I.e. they are not accessed directly but they are accessed > >> either via fronted Apache or via proxy (like squid or oops) in > >> accelerated mode. As I understand advisory in this case backend > >> mod_perl server is not vulnerable since attacker do not have direct > >> access to it. > >> > >> Can anybody confirm it? > > > >If your backend is proxied via mod_proxy or mod_accel then backend is not > >vulnerable because both modules do not accept client's chunked body at all. > >I can not say anything about Squid and Oops. > > > > They have in the changelog for 1.3.26: > * A large number of fixes in mod_proxy including: adding support >for dechunking chunked responses, correcting a timeout problem > <...> > > Does this change anything? I.e. backend is still safe? In 1.3.24 mod_proxy try to support chunked responses that go from servers. It never supports client's chunked body. As far as I know now there are no browsers that send chunked body. Igor Sysoev http://sysoev.ru
Re: Apache Web Server vulnerability
On Thu, 20 Jun 2002, Lupe Christoph wrote: > On Thursday, 2002-06-20 at 18:22:10 +0400, Igor Sysoev wrote: > > On Thu, 20 Jun 2002, Lupe Christoph wrote: > > > > > and the mod_perl module seems to prevent the crash: > > > > > > > telnet proxy.customer.de 80 > > > > Trying 213.155.64.138... > > > > Connected to proxy.customer.de. > > > > Escape character is '^]'. > > > > POST /x.html HTTP/1.1 > > > > Host: proxy.customer.de > > > > Transfer-Encoding: chunked > > > > > > > > 8000 > > > > Rapid 7 > > > > 0 > > > > > > > > > > > > ^] > > > > telnet> Connection closed. > > > > > > Does mod_perl do it's own de-chunking? > > > So mod_perl does not return any response ? > > > There are two ways to prevent crush with particular URI: > > 1. return 411 error if client send chunked body (standard mod_proxy, > >mod_cgi and mod_isapi do it); > > 2. ignore body at all. > > > I suspect second in your case. > > Sorry that is not the answer to my question - the question is if my > code gets a chance to do *anything*, or will the httpd code just > crash at a later time? It does not crash like a non-mod_perl httpd. I think if you Apache does not send any response then it vulnerable with this particular URI. I've tried you request with plain Apache - one process starting to eat CPU without faults. Igor Sysoev http://sysoev.ru
Re: Apache Web Server vulnerability
On Wed Jun 19 17:54:02 2002 +0400 Igor Sysoev wrote: >On 19 Jun 2002, Ilya Martynov wrote: > >> If you still do not know about it: >> >> http://httpd.apache.org/info/security_bulletin_20020617.txt >> >> Now mod_perl question. mod_perl servers often are used as backend >> servers. I.e. they are not accessed directly but they are accessed >> either via fronted Apache or via proxy (like squid or oops) in >> accelerated mode. As I understand advisory in this case backend >> mod_perl server is not vulnerable since attacker do not have direct >> access to it. >> >> Can anybody confirm it? > >If your backend is proxied via mod_proxy or mod_accel then backend is not >vulnerable because both modules do not accept client's chunked body at all. >I can not say anything about Squid and Oops. > They have in the changelog for 1.3.26: * A large number of fixes in mod_proxy including: adding support for dechunking chunked responses, correcting a timeout problem <...> Does this change anything? I.e. backend is still safe? -- ☻ Ričardas Čepas ☺
Re: Apache Web Server vulnerability
On Thursday, 2002-06-20 at 18:22:10 +0400, Igor Sysoev wrote: > On Thu, 20 Jun 2002, Lupe Christoph wrote: > > > and the mod_perl module seems to prevent the crash: > > > > > telnet proxy.customer.de 80 > > > Trying 213.155.64.138... > > > Connected to proxy.customer.de. > > > Escape character is '^]'. > > > POST /x.html HTTP/1.1 > > > Host: proxy.customer.de > > > Transfer-Encoding: chunked > > > > > > 8000 > > > Rapid 7 > > > 0 > > > > > > > > > ^] > > > telnet> Connection closed. > > > > Does mod_perl do it's own de-chunking? > So mod_perl does not return any response ? > There are two ways to prevent crush with particular URI: > 1. return 411 error if client send chunked body (standard mod_proxy, >mod_cgi and mod_isapi do it); > 2. ignore body at all. > I suspect second in your case. Sorry that is not the answer to my question - the question is if my code gets a chance to do *anything*, or will the httpd code just crash at a later time? It does not crash like a non-mod_perl httpd. Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm|
