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/
