Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 20 May 2010 08:27:56 +0400
From: Solar Designer <>
Subject: Re: [oCERT-2010-001] multiple http client unexpected download filename vulnerability

On Wed, May 19, 2010 at 03:28:18PM +0200, Ludwig Nussel wrote:
> Serving dot files is a neat trick indeed, I've overlooked that
> paragraph in the ocert advisory. Nevertheless I'm not convinced it's
> worth changing wget's default behavior in the proposed way. So I can
> understand upstream here.

As far as I'm aware, at the time of the initial oCERT notification, the
wget upstream was represented by Micah Cowan, who was about to resign.
And he did:

oCERT has re-notified the new upstream shortly before publishing the
advisory (we decided this was not enough of a reason to introduce a
further pre-public-disclosure delay).  I don't think the new wget
upstream has made a determination on this issue yet; at least I'm not
aware of that.


For those producing back-ports for lftp, the approach to take is to
download 4.0.5 and 4.0.6 from:

Then diff them with:

diff -purx configure -x po -x 'Makefile*' -x '*.in' -x '*.in.h' -x m4 -x lib -x build-aux -x '*.m4' lftp-4.0.5 lftp-4.0.6

This is a small and relevant diff, which should be easy to manually turn
into a patch for just the relevant changes.  The NEWS file mentions these:

* use O_EXCL flag when xfer:clobber is off.
* better validation of server-provided file name.
* new setting xfer:auto-rename (off by default).

All three of the above are relevant, especially the last one.  A test
case is downloading WordPress with:


Vulnerable lftp will silently produce a file named like
wordpress-2.9.2.tar.gz instead of latest.tar.gz.  Fixed lftp will
produce latest.tar.gz unless the user explicitly sets xfer:auto-rename.

For Owl, we simply updated to lftp 4.0.7.  Our -stable branch uses a
too-old lftp (not yet vulnerable), so we did not require a back-port.

When testing tools other than lftp, please note that the WordPress test
case tests for one of two attack-usable HTTP headers only
(Content-Disposition but not Location).  We did test a handful of other
tools, but only three - lftp, lwp-download, wget - were found vulnerable.
curl, ELinks were found not vulnerable.  Lynx was inconclusive in Hank's
testing (and we did not investigate further).


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.