Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 25 Sep 2015 16:04:13 -0400 (EDT)
Subject: Re: CVE request for wget

Hash: SHA256


We really don't understand what set of expectations led to this
becoming a CVE request for a vulnerability in wget. We know that a
design goal of Tails is to prevent Internet servers from discovering
the IP address of a machine running Tails. Possibly it's a design
requirement of Tails that a developer needs to "torify" every piece of
Internet client software before it can be shipped with the Tails
distribution, and that a failure of a torify step is, by definition, a
Tails vulnerability. (torify is explained on the page.)
If that's true, then a CVE ID can be provided for the Tails product.

One of the things that happened is that the upstream wget developer
made a change that we would categorize as a
functionality/usability-versus-privacy tradeoff. Specifically,
upstream decided it was better to omit the automatic fallback from
passive to active. As far as we can tell, upstream hasn't announced
this as a "wget vulnerability" -- they just reconsidered the tradeoff.
A reconsidered tradeoff is generally outside the scope of CVE. We
believe that reasonable behavior for wget on Tails is very different
from reasonable behavior for the standard upstream distribution.

Also, references such as suggest that
there's a concern even without Tor: "An second information leak
scenario is leaking of an internal IP address (e.g. from a private
range) to an external entity when connecting through NAT."

So, some of the options for sets of expectations are:

1. No piece of Internet client software may support any protocol
feature in which the end-client machine's IP address is sent as part
of application data. If any such feature is supported, it is a
vulnerability because someone might try to use that protocol feature
in conjunction with NAT, or Tor, or another type of proxy, and privacy
would be compromised. This would, for example, mean that every FTP
client must either completely rip out support for active mode, or at
least warn the user that it is unsupported and require explicit user
confirmation before proceeding.

2. Internet client software developers are responsible for providing a
privacy-friendly configuration setting in which the end-client
machine's IP address is never sent as part of application data. In the
wget case, maybe this would be a wgetrc line of "passive_ftp = always"
or "active_ftp = off" (i.e., active mode would never be used, either
first or as a fallback).

3. Internet client software developers have a much wider range of
reasonable behavior, although wrong documentation needs to be avoided.
Specifically, NAT users aren't entitled to expect that their IP
address (in a case such as FTP) will remain secret unless a developer
chooses to explicitly document NAT privacy behavior. Tor users aren't
entitled to expect that all of the necessary torify steps have been
done in the upstream distribution. The torify steps are the
responsibility of Tor-oriented products such as the Tor Browser Bundle
(and possibly Tails, if torifying everything is their policy).

(As one of the references mentioned, missing torify steps for wget
aren't a new concept; see the
post from 2012.)

Currently, for CVE assignment, options 1 and 2 are more or less false,
and option 3 is more or less true.

If an upstream developer makes a decision to do privacy hardening to
avoid address disclosure, that's great, but regardless of the decision,
there typically won't be a CVE ID assigned to that upstream product.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1


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.