![oss-sec logo](/images/oss-sec-logo.png)
oss-sec mailing list archives
Re: [oCERT-2010-001] multiple http client unexpected download filename vulnerability
From: Solar Designer <solar () openwall com>
Date: Thu, 20 May 2010 08:27:56 +0400
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: http://lists.gnu.org/archive/html/bug-wget/2010-04/msg00027.html 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: http://ftp.yars.free.net/pub/source/lftp/old/ 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: lftpget http://wordpress.org/latest.tar.gz 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). Alexander
Current thread:
- [oCERT-2010-001] multiple http client unexpected download filename vulnerability Daniele Bianco (May 17)
- Re: [oCERT-2010-001] multiple http client unexpected download filename vulnerability Florian Weimer (May 17)
- Re: [oCERT-2010-001] multiple http client unexpected download filename vulnerability Ludwig Nussel (May 18)
- Re: [oCERT-2010-001] multiple http client unexpected download filename vulnerability Solar Designer (May 18)
- Re: [oCERT-2010-001] multiple http client unexpected download filename vulnerability Ludwig Nussel (May 19)
- Re: [oCERT-2010-001] multiple http client unexpected download filename vulnerability Solar Designer (May 19)
- Re: [oCERT-2010-001] multiple http client unexpected download filename vulnerability Vincent Danen (Jun 10)
- Re: [oCERT-2010-001] multiple http client unexpected download filename vulnerability Solar Designer (May 20)
- Re: [oCERT-2010-001] multiple http client unexpected download filename vulnerability Solar Designer (May 20)
- Re: [oCERT-2010-001] multiple http client unexpected download filename vulnerability Ludwig Nussel (May 18)
- Re: [oCERT-2010-001] multiple http client unexpected download filename vulnerability Florian Weimer (May 17)
- Re: [oCERT-2010-001] multiple http client unexpected download filename vulnerability Steven M. Christey (Jun 09)