Re: [Bug-wget] security risk of unexpected download filenames

[Micah Cowan]

Note: I had previous discussions with a Daniele Bianco at oCERT about
this. They were off-list, and they explicitly requested I not converse
about it publicly until a coordinated fix/announcement could be effected.

On 05/19/2010 09:47 PM, Solar Designer wrote:
> Giuseppe, Micah, all -
> 
> As I hope you're aware, oCERT has published an advisory on a security
> issue with lftp, wget, and libwww-perl.  lftp and libwww-perl have fixed
> the issue.  wget didn't.
> 
> http://www.ocert.org/advisories/ocert-2010-001.html
> 
> Here's a demonstration of an attack on what I think is a typical wget
> cron job:
> 
> http://www.openwall.com/lists/oss-security/2010/05/18/13
> 
> The attack provides a .wgetrc, which enables a second invocation of the
> cron job to overwrite a file such as .bash_profile.  This is just one
> example.  Please do not "fix" this by treating ".wgetrc" specially.

Nor by treating anything with an initial "dot" specially, I imagine. On
Windows, *.ini files probably provide a similar problem, and reliably
predicting which names are "dangerous" is a losing game.

> Here's an unofficial patch for the issue:
> 
> http://www.openwall.com/lists/oss-security/2010/05/17/2
> 
> Now that we have a proof-of-concept real-world attack scenario and we
> readily have a patch, would you possibly consider fixing this upstream?

Summary of my understanding: the problem results from wget's obedience
of filenames from redirects, which allows the remote end to arbitrarily
choose the filename of a single file. This presents the attack
opportunity you describe, but only in situations where wget is being
invoked to download a file directly into the home directory (which is a
bad idea without -O, but I'll grant you not everyone will realize that,
so it should probably be avoided there).

Similar situations can arise from running "wget --recursive
--no-directories" in the home directory. In this case, I don't think we
should work to avoid server-chosen names, since that's a fundamental
functionality change to wget, and in any case can't realistically be
done (I see your patch doesn't try). Instead, for this case we should
probably add something to the documentation for --no-directories warning
that you shouldn't use it if wget will be placing files directly in your
home directory or a similar sensitive location.

In conversations with Daniele, it sounded like you weren't concerned
about --content-disposition (whose entire purpose is to let the server
choose a name) because it has to be explicitly enabled. There had
previously been plans to make this the default, but it was disabled by
default because the current implementation can result in extra roundtrip
request/response with the server (it also always leaves them in the
download root, instead of in the "directory" containing the file, IIRC).
This makes a good case, even once those inefficiencies are resolved, for
leaving it as not the default.

-- 
Micah J. Cowan
http://micah.cowan.name/