Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

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