Date: Thu, 1 Oct 2015 18:57:26 -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 >> ... 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. > That's a reasonable position, please instead issue a CVE for Tails. Use CVE-2015-7665 for the Tails vulnerability corresponding to the http://git.savannah.gnu.org/cgit/wget.git/commit/?id=075d7556964f5a871a73c22ac4b69f5361295099 commit. If there is any additional Tails vulnerability related to this, another CVE ID may be needed. For example, https://lists.gnu.org/archive/html/bug-wget/2015-08/msg00050.html says to be 100% sure, you should add --passive-ftp to your command line. If you don't do that, your /etc/wgetrc or ~/.wgetrc could include --no-passive-ftp (or passiveftp = off). If Tails is supposed to try to ensure that, perhaps there's a requirement to have something like: alias wget="wget --passive-ftp" in a system-wide location (possibly /etc/bash.bashrc). The concept of CVE IDs for "failure of a torify step" issues is new, and we aren't sure of the best approach. Responding to: > From: Andreas Stieger <astieger@...e.com> > Date: Tue, 29 Sep 2015 13:12:37 +0200 >> We really don't understand what set of expectations led to this >> becoming a CVE request for a vulnerability in wget. > Possibly assignments for CWE-200 including CVE-2000-0649, CVE-2002-0422 > relating to exposure if an internal IP address of a communication partner. The difference here is that sending the client IP address within the TCP application data is inherently a part of the FTP protocol. That's why we've been reluctant to consider this a vulnerability in the upstream wget distribution. This is also a situation in which the need to torify may be different with IPv6 than with IPv4. IPv4 NAT environments are sometimes set up so that clients cannot successfully use FTP in active mode. Perhaps because of this, it is currently common for FTP clients to use passive mode by default. With IPv6, it is probably more likely that a client can successfully use FTP in active mode. There might be, now or in the near future, FTP clients that try active mode for IPv6 FTP servers. Thus, when Tor is used, there may be information disclosure in EPRT commands even when there hadn't been information disclosure in PORT commands. (Of course, a PORT command may be sent even when active mode is ultimately going to fail. The point is that, for communication between a normal FTP client and a normal IPv4 FTP server, active mode will often never be attempted.) - -- 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 iQIcBAEBCAAGBQJWDboGAAoJEL54rhJi8gl5WzwP/3vIX0WkQy2KIhjGgI+4dhcZ lPT9GynzMKGCG5U4Fnqez5lfMammTAmyU6kRCohUSWLfxPkDNDZM5kf5fbnBcgPr ebq0awx7oj9y506x0YHMw9zYtd1C1uaY18BEdVsZcTs8E2+nBMayAW8+T+o9OVyo bqImRG5lIj+c68VJuY6mmePDRpqXohOZ4I+Vv5pzBim4cNKcYA28upErh5mZwYYj rFct5GV3Jc//yAJPhtZMhRIaf+bXcKYoyL3bze+bFLPnLUQSJV/8ezcB2WWE4+Uu 1G4iYD0ZOrmHmbZfJs32ZF2QHdoWMRQzNNN0JQk60iB/4nWuP5Ns28QH3Vu2CRw1 XqyAnaChCEX+Xead71z5Db5ugdIOgTo1hPZ5DaUlU1EJ3T+SYCiwJCCPIELXcGgN unlml3il98COee1E7tOFudguGlHq0PwHGPixlQVMtZSAHIbuec+Vh4LAbsEE5rTC Hrsp3xRtUgQNKHiuYgDNNH03fh5e7A75RR6CPaIuTPKjMRCxVPtTzqyhrQYAkc/f 4kEQioiLK/2obNO7EuiitWBaQQGZHZgbFxWnz8F08ZGagg0hQj2QtYeN0SBp+iqY CEqfUoihoZharTag3XPLf3xA2C8w4GGkWUI6LcyUtrlzoVoSaj0nB6Mt6tWaq6cT QD/3LlAZGdgiRu5bEuld =9V0C -----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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ