bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Solar Designer
Subject: Re: [Bug-wget] security risk of unexpected download filenames
Date: Fri, 21 May 2010 01:47:01 +0400
User-agent: Mutt/1.4.2.3i

Micah,

Thank you for your detailed analysis and reply.

On Thu, May 20, 2010 at 01:55:24PM -0700, Micah Cowan wrote:
> 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.

That's correct.  Now that the oCERT advisory has been published, we can
and should discuss in public.  oCERT did not wait for wget to be fixed
in part because you indicated you did not intend to fix the issue,
as well as because the pre-disclosure delay was already excessive for
this issue (way beyond what oCERT's policy says...) and because the lftp
fix was made public (without coordination with oCERT... who only learned
of that with a 1-month delay).  The lftp fix did not mention/explain the
security relevance of the changes, though.

> On 05/19/2010 09:47 PM, Solar Designer wrote:
> > 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.

Exactly.

> 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).

That's correct, except for the "only ... into the home directory" part.
In practice, this restriction may apply most of the time, but there are
scenarios where a download into another directory could also allow for
an attack.  For example, a cron job on a web hosting account may use
wget to update a file below the "document root".  An attack would be to
provide an .htaccess file instead.  Another attack would be to provide
an index.html file, assuming that it did not exist - say, index.php
existed, but index.html would commonly take precedence.  Thus, a stock
quotes feed (or whatever), when compromised, would deface the homepage.
Without the wget issue, only a web page actually displaying the content
obtained from the remote would be affected.

> 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.

I agree.  (The patch is Florian's, not mine, but it looks good to me.)

> 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.

Yes, this fully matches my understanding.

I did not previously know your non-security reasons for having
--content-disposition disabled by default.  Thank you for explaining
that.  Now we also have a security reason for keeping that default.

Thanks again,

Alexander



reply via email to

[Prev in Thread] Current Thread [Next in Thread]