Bug 602797 - (CVE-2010-2252) CVE-2010-2252 wget: multiple HTTP client download filename vulnerability [OCERT 2010-001]
CVE-2010-2252 wget: multiple HTTP client download filename vulnerability [OCE...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
http://www.ocert.org/advisories/ocert...
impact=low,public=20100517,reported=2...
: Security
Depends On: 833831 1062190
Blocks: 1062205
  Show dependency treegraph
 
Reported: 2010-06-10 15:14 EDT by Vincent Danen
Modified: 2015-07-31 02:27 EDT (History)
5 users (show)

See Also:
Fixed In Version: wget 1.13.3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: CVE-2010-2251
Environment:
Last Closed: 2015-01-22 12:29:54 EST
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 (8.52 KB, patch)
2010-06-21 18:12 EDT, Vincent Danen
no flags Details | Diff

  None (edit)
Description Vincent Danen 2010-06-10 15:14:42 EDT
+++ This bug was initially created as a clone of Bug #591580 +++

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.

--- Additional comment from vdanen@redhat.com on 2010-05-15 08:54:02 EDT ---

Florian noted the following as testcases for wget:

$ wget http://www.postbank.de/-snm-0184304830-1273865547-04f6f00001-0000000023-1273866968-enm-privatkunden/fonds_boerse.htm
(adds ;jsessionied= to the stored file name)

There's yet another case, but that only results in an index.html
download.

$ wget http://www.enyo.de/fw

--- Additional comment from vdanen@redhat.com on 2010-05-17 10:51:26 EDT ---

This is now public:

http://www.ocert.org/advisories/ocert-2010-001.html

--- Additional comment from vdanen@redhat.com on 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 1 Vincent Danen 2010-06-10 15:18:58 EDT
MITRE has assigned the name CVE-2010-2252 to this issue.

Additional comments on oss-security from Solar Designer (http://www.openwall.com/lists/oss-security/2010/05/18/13) indicate that this is something we should be looking at for wget:

I disagree.  Uses from scripts and cron jobs are too common, and they
often don't care to specify an output filename explicitly.

Let's suppose there's a cron job like this:

1 * * * *       wget http://www.openwall.com/pvt/wget/log &> /dev/null

If the server is malicious or compromised, it can have:

RedirectMatch log $1/pvt/wget/.wgetrc

in .htaccess, and

reject=; exec id
output-document=.bash_profile

in .wgetrc.  When the cron job runs for the first time after the above
changes made on the server, it does:

02:01:02 (2.64 MB/s) - `.wgetrc' saved [47/47]

At this point, .wgetrc is on the client system.  The second time the
cron job runs, it does:

03:01:02 (2.99 MB/s) - `.bash_profile' saved [47/47]

This has happily overwritten my .bash_profile file.

(I replaced "/dev/null" in the cron job with another filename for
obtaining these wget output lines.)

When I am logging in to the affected account, I get the output of "id".
Of course, the shell command could as well be nastier than that.

Although I used a somewhat tricky approach in the above exploit,
eventually making wget overwrite a file, it is also possible to mount
attacks that do not rely on overwriting any files.  Many programs
support optional startup/config files of fixed/known/guessable names
that a malicious or compromised server could provide.  In fact, I've
just demonstrated this attack against wget itself, but it could also
work against another program.
Comment 2 Vincent Danen 2010-06-21 18:12:18 EDT
Created attachment 425763 [details]
patch to correct the issue

This patch is based on Florian's patch posted on oss-security: http://article.gmane.org/gmane.comp.security.oss.general/2908 and works on Red Hat Enterprise Linux 5.
Comment 3 Vincent Danen 2010-06-22 12:55:52 EDT
On Red Hat Enterprise Linux 3 and 4 (wget 1.10.2), the first issue (the appended jsessionied) is not seen, but the malicious server redirect is a problem.

On Red Hat Enterprise Linux 5 (wget 1.11.4), both issues are apparent.
Comment 4 Josh Bressers 2010-08-09 14:26:54 EDT
I am changing the severity of this flaw to low. It is not trivial to exploit. It needs a combination of events to be successful.
Comment 6 Vincent Danen 2010-08-17 16:04:29 EDT
This has now been addressed upstream and the next version of wget will correct this issue (patch included in the message):

http://lists.gnu.org/archive/html/bug-wget/2010-07/msg00076.html
Comment 9 Tomas Hoger 2014-02-03 05:13:38 EST
(In reply to Vincent Danen from comment #2)
> Created attachment 425763 [details]
> patch to correct the issue
> 
> This patch is based on Florian's patch posted on oss-security:
> http://article.gmane.org/gmane.comp.security.oss.general/2908 and works on
> Red Hat Enterprise Linux 5.

Upstream patch uses trust_server_names and --trust-server-names:

http://git.savannah.gnu.org/cgit/wget.git/commit/?id=3e25a9817f47fbb8660cc6a3b2f3eea239526c6c
Comment 12 Tomas Hoger 2014-02-06 07:37:33 EST
External References:

http://www.ocert.org/advisories/ocert-2010-001.html
Comment 13 errata-xmlrpc 2014-02-10 12:29:48 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2014:0151 https://rhn.redhat.com/errata/RHSA-2014-0151.html
Comment 14 Vincent Danen 2015-01-22 12:29:54 EST
Statement:

Red Hat Enterprise Linux 5 is now in Production 3 Phase of the support and maintenance life cycle. This has been rated as having Low security impact due to the series of events required to successfully exploit it, and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.

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