Date: Fri, 25 Sep 2015 16:04:13 -0400 (EDT) From: cve-assign@...re.org To: austinenglish@...il.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE request for wget -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > https://mailman.boum.org/pipermail/tails-dev/2015-August/009370.html > https://lists.gnu.org/archive/html/bug-wget/2015-08/msg00020.html > http://git.savannah.gnu.org/cgit/wget.git/commit/?id=075d7556964f5a871a73c22ac4b69f5361295099 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 https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO 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 https://bugzilla.suse.com/show_bug.cgi?id=944858#c4 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 https://lists.torproject.org/pipermail/tor-talk/2012-April/024040.html 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 http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWBabRAAoJEL54rhJi8gl5PngP/3vNxfQYa3M50eLYPNsMzreo LN48gBIzf96DwffplTex2BgJRHpXKEdvQvetvjmc3TWb77Dl8J9F9pOfwCKAapCI 7wMoyR2f/WpaDs0RI4NIeGjh4UorLlN5NaRdIOfdvxfGD4rLSJY4wz12AvGvaUh9 Ynk8JlBbx++CSsEF6WCfOYFPSKDzF2c7hYrR2IR7+QPiKo7YSDp7Jy/gp2FuyI4p GH6T6SrbDHuw9YqtNACzp+TCRGJxuqAeXVhGqNdViiLZurhTl0hHkl4TsRIHwDPn SmaMnLLx3YbTwkpC1vH9aGTVeKCbXjt7RPDTy1v2dZSUMiljJXca892NkfJOqvXx piy0afjD9aXNhW1C1nkVlPC0zrCwa4cxxhm1M/T9k+18L1weYixl/pQnlZYAa+OH Lc5/YQPcpAqHQkk1Kyksl+qFjgmeXkUToPd1jgss6YVuuBnHku3gZjwTn5msM3i/ wN7FRBAB8CQvMCW/7Gkr0uYBfdlTo9o7tuvB5whdTzr2xyXpey0ns7axNX1FaY7b ut8HonGQryLBZexBdskOLVr0H+ihRjCd7AX/ijUUo5o8mNSAG/s0Y3Uh2W8MGrir n9p9k/r+aH82u+yoeJuTUT2QpWfJO4nYB6m84d8gl51gQlX2+FrXaRcFXkJkwrUY g66Lp4JhmaTWTiVpf1yX =RjXG -----END PGP SIGNATURE-----
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.