Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Web Browser)  >   wget Vendors:   GNU [multiple authors]
wget Lets Remote Users Create or Overwrite Files in Certain Directories
SecurityTracker Alert ID:  1012472
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Dec 10 2004
Impact:   Modification of system information, Modification of user information
Exploit Included:  Yes  
Version(s): 1.9.1 and prior versions
Description:   A vulnerability was reported in wget. A remote user may be able to create or overwrite files on the target user's system.

Jan Minar reported that a remote server can create or overwrite arbitrary files in the connected target user's current directory (or subdirectories) with the privileges of the target user.

It is also reported that in conjunction with DNS poisoning attacks, the remote server can create or overwrite files in and below the parent directory on the target user's system.

Wget does not properly validate user-supplied input. A remote user can bypass the filtering mechanism if DNS can be modified so that '..' resolves to an IP address.

It is also reported that a specially crafted HTTP response can include control characters to overwrite portions of the terminal window.

Impact:   A remote server can create or overwrite arbitrary files in certain directories on the target user's system. Files are created/overwritten with the privileges of the target user.
Solution:   No solution was available at the time of this entry.
Vendor URL: (Links to External Site)
Cause:   Access control error, Input validation error
Underlying OS:  Linux (Any), UNIX (Any)

Message History:   None.

 Source Message Contents

Subject:  wget: Arbitrary file overwriting/appending/creating and other vulnerabilities

[Message part 1 (text/plain, inline)]

Package: wget
Version: 1.8.1-6.1
Version: 1.9.1-8
Tags: security
Severity: grave

The most severe of these bugs is that wget(1) allows the remote attacker
to overwrite arbitrary files the user running wget has permissions to
(woody), or any files in and below the current directory (sarge), or,
with the help of DNS poisoning, in and below the parent directory
(sarge, woody).  At the same time, wget is being widely used.  That's
why the severity.

The 1.8 version severity is mainly a Debian issue, and we cannoct expect
it will be fixed upstream, as the code differs vastly between the

A cropped version of my BugTraq post follows:

(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/   [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.


(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


A proof of concept is attached.

See [1] the bug page for a proposal of how to solve this.



 )^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

Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2020, LLC