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 .bash_profile 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:
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
Content-Type: text/html; charset=UTF-8
wget will automatically follow the redirect and will download a malicious .bash_profile file from a malicious FTP server. It will fail to rename the file to the originally requested filename of 'safe_file.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.
Name: GNU wget project
Upstream: Dawid Golunski
Created attachment 1165694 [details]
Proposed upstream patch
I've just released wget 1.18 with the fix:
I am going to publicly announce the new version in few hours
Public via https://lists.gnu.org/archive/html/info-gnu/2016-06/msg00004.html
CVE patch made a regression, this one fixes it:
Use wget with "-O" option to explicitly specify the output filename.
This issue has been addressed in the following products:
Red Hat Enterprise Linux 7
Via RHSA-2016:2587 https://rhn.redhat.com/errata/RHSA-2016-2587.html