Bug 591580 - (CVE-2010-2251) CVE-2010-2251 lftp: multiple HTTP client download filename vulnerability [OCERT 2010-001]
CVE-2010-2251 lftp: multiple HTTP client download filename vulnerability [OCE...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
http://www.ocert.org/advisories/ocert...
public=20100517,reported=20100512,sou...
: Security
Depends On: 602836 602838 617870 617871
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-12 11:37 EDT by Vincent Danen
Modified: 2015-10-15 17:11 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: CVE-2010-2252 CVE-2010-2253 (view as bug list)
Environment:
Last Closed: 2015-07-29 10:15:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch to correct the issue (4.92 KB, patch)
2010-06-10 16:12 EDT, Vincent Danen
no flags Details | Diff
Corrected patch with manpage changes (5.55 KB, patch)
2010-07-29 10:28 EDT, Ondrej Vasik
no flags Details | Diff

  None (edit)
Description Vincent Danen 2010-05-12 11:37:57 EDT
The draft advisory from oCERT follows:

The lftp, wget and lwp-download applications are ftp/http clients and file
transfer tools supporting various network protocols. The lwp-download
script is shipped along with the libwww-perl library.

Unsafe behaviours have been found in lftp and lwp-download handling the
Content-Disposition header in conjunction with the 'suggested filename'
functionality.

Additionally unsafe behaviours have been found in wget and lwp-download in
case of HTTP 3xx redirections during file dowloading. The two applications
automatically use the URL's filename portion specified in the Location
header.

Implicitly trusting the suggested filenames results in a saved file that
differs from the expected one according to the URL specified by the user.
This can be used by a malicious attacker to silently write hidden and/or
initialization files under the user's current directory (e.g. .login,
.bashrc).

The impact of this vulnerability is increased in the case of lftp/lftpget
as the default configuration allows file overwrite without prompting
confirmation to the user. In case of lftp the get1 command is affected.
This command can be invoked directly by the user from lftp's command line
interface or indirectly by using the lftpget script, packaged within lftp
distribution.

Affected version:

lftp <= 4.0.5
wget <= 1.12
libwww-perl <= 5.834

Fixed version:

lftp >= 4.0.6
wget N/A
libwww-perl >= 5.835

Credit:

Vulnerability discovered and reported by Hank Leininger and Solar Designer
under the Openwall Project, with further analysis by Daniele Bianco of
oCERT.
Comment 4 Vincent Danen 2010-05-15 08:53:15 EDT
No patches from upstream are available on any of these, however lftp 4.0.6 does correct the issue, so we should be able to generate a patch based on a diff between 4.0.5 and 4.0.6.  The NEWS file indicates:

* 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 issues are relevant, but the last is the big one.  To test, try:

lftpget http://wordpress.org/latest.tar.gz

A vulnerable lftp will produce wordpress-2.9.2.tar.gz silently, whereas a fixed lftp will generate latest.tar.gz unless the user explicitly sets xfer:auto-rename.  This WordPress example is only useful when testing the Content-Disposition HTTP header, not Location.

libwww-perl 5.835 is also supposed to fix this issue, so a diff between 5.834 and 5.835 should produce a relevant patch.
Comment 6 Vincent Danen 2010-05-17 10:51:26 EDT
This is now public:

http://www.ocert.org/advisories/ocert-2010-001.html
Comment 7 Vincent Danen 2010-05-18 11:17:25 EDT
Florian made a post to oss-security with a preliminary patch for wget.  It probably requires some upstream review as it does add a new configuration option:

http://article.gmane.org/gmane.comp.security.oss.general/2908

However, Ludwig Nussel indicates that wget's behaviour is acceptable and probably doesn't require fixing at all, as wget does not overwrite existing files by default (adds suffixes like .1 and .2 to the new file if it already exists), and also prints the file name it used so there are no surprises.

In light of that, I would consider this a non-issue for wget, especially considering how intrusive the patch is for a backport.
Comment 8 Vincent Danen 2010-06-10 15:26:04 EDT
MITRE has assigned the following CVE names for the three packages noted in this advisory, and as a result this bug has been cloned to distinguish between the three:

CVE-2010-2251: lftp
CVE-2010-2252: wget (see bug #602797)
CVE-2010-2253: perl-libwww-perl (see bug #602800)
Comment 9 Vincent Danen 2010-06-10 16:12:39 EDT
Created attachment 423030 [details]
patch to correct the issue

This patch is the relevant differences between 4.0.5 and 4.0.6, and also includes the following change from 4.0.7:

* GetJob.cc: make xfer:clobber=no by default.
Comment 12 Vincent Danen 2010-06-10 16:49:56 EDT
Created lftp tracking bugs for this issue

Affects: fedora-all [bug 602836]
Comment 14 Fedora Update System 2010-06-11 08:25:50 EDT
lftp-4.0.8-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/lftp-4.0.8-1.fc12
Comment 15 Fedora Update System 2010-06-30 11:09:52 EDT
lftp-4.0.8-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 16 Vincent Danen 2010-07-24 11:18:19 EDT
Statement:

This issue did not affect the version of lftp as shipped with Red Hat Enterprise Linux 3 and 4 as they did not include support for renaming files to a server-suggested file name.
Comment 20 Ondrej Vasik 2010-07-29 10:28:55 EDT
Created attachment 435311 [details]
Corrected patch with manpage changes

I added manpage corrections into the patch and changed it to respect xfer:clobber ... Old version of the patch had regression that it failed to rename the file if xfer:clobber was activated via conf file. This one works for me in all cases correctly.

As a side note - as lftp doesn't use temporary file, it still deletes the old file if it exists - as it downloads the file with the requested name and then it renames it to the servesuggested name.
Comment 21 errata-xmlrpc 2010-08-02 16:20:37 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2010:0585 https://rhn.redhat.com/errata/RHSA-2010-0585.html

Note You need to log in before you can comment on or make changes to this bug.