Story 2TS1 wget prior to 1.16 allows for a web server to write arbitrary files on the client side

wget prior to 1.16 allows for a web server to write arbitrary files on the client side

by
Anonymous Coward
in security on (#2TS1)
Here's a concern for most of us. Be aware that the popular program wget, in versions prior to 1.16, allows for a FTP server to write arbitrary files on the client side. Wget is commonly used in shell scripts to get files or web pages from servers for further processing locally. Wget has many other uses as well, and is an important part of much command line sorcery.

A Metasploit module is available for testing:

https://github.com/rapid7/metasploit-framework/pull/4088

the disclosure is here:

https://community.rapid7.com/community/metasploit/blog/2014/10/28/r7-2014-15-gnu-wget-ftp-symlink-arbitrary-filesystem-access

Redhat's bug is here:

https://bugzilla.redhat.com/show_bug.cgi?id=1139181
Reply 10 comments

This one is really serious (Score: 2, Informative)

by engblom@pipedot.org on 2014-10-29 12:37 (#2TS4)

I think this one has bigger potential than the bash-bug recently discussed. Very few are passing stuff down to a bash shell unfiltered comparing to downloading with wget. Aren't almost all admins pasting in urls and downloading with wget on servers if they need a file from the net? It will not help if you checked the MD5 sum of what you downloaded as the vulnerability was in the client and not in the package you downloaded.

It is enough that one important server get compromized by this vulnerability and it will spread like a wild fire. An exploit will for sure check if the computer wget is running on also is running a web server. If it does, it will probably infect the web server for further spreading.

Re: This one is really serious (Score: 2, Insightful)

by zafiro17@pipedot.org on 2014-10-29 13:17 (#2TS5)

Agreed. Also: with the exception of curl, there aren't really any good alternatives to wget. It's good at what it does, and gets worked into all sorts of useful scripts.

Re: This one is really serious (Score: 4, Informative)

by seriously@pipedot.org on 2014-10-29 15:08 (#2TSB)

Note that it applies only to using wget with both an FTP connexion and recursive flags, which significantly reduces it's potential.

Not to say that it is not a serious one, it is, but it's not as bad as wget on a http url for a single file (which is something I do daily). Now, that would be really messy.

Re: This one is really serious (Score: 1)

by fnj@pipedot.org on 2014-10-29 17:14 (#2TSJ)

I think this one has bigger potential than the bash-bug recently discussed. Very few are passing stuff down to a bash shell unfiltered
I do not think you understand the mechanism for ShellShock.

What's the big deal? (Score: 0)

by Anonymous Coward on 2014-10-29 13:26 (#2TS6)

Isn't wget a hacker tool anyway?

/trollface

In all seriousness though, this definitely has potential to be a pretty serious issue given how widespread wget's use is, coupled with this probably not being taken as seriously outside of admin circles. Considering how much damage could be done under the guise of offering up instructions for downloading otherwise innocuous content on some FOSS help page somewhere seems enough reason to take this pretty seriously.

Vulnerability Note VU#685996 (kb.cert.org) (Score: 2, Informative)

by Anonymous Coward on 2014-10-29 14:36 (#2TSA)

ftp web server? (Score: 2)

by ticho@pipedot.org on 2014-10-29 16:28 (#2TSG)

Maybe I'm just not seeing the connection, but why does the summary talk about a web server if the issue is with FTP?

ftp web server? (Score: 0)

by ticho@pipedot.org on 2014-10-29 16:30 (#2TSH)

Maybe I'm just not seeing the connection, but why does the summary talk about a web server if the issue is with FTP?Edit: Sorry for the doublepost, damn trains and tunnels. :-)

Re: ftp web server? (Score: 1)

by evilviper@pipedot.org on 2014-10-29 19:33 (#2TSN)

If you look at the pipe history, you'll see the submission from the AC repeatedly said "web" server, and the editors simply corrected one of the two to FTP.

Changing the subject line after publication can break links, so I'd rather not, except in extreme cases.