Re: [Bug-wget] [oss-security] CVE Request - Gnu Wget 1.17 - Design Error Vulnerability

[Tim Rühsen <tim.ruehsen () gmx de>]

On Donnerstag, 11. August 2016 21:34:14 CEST Kurt Seifried wrote:
> On Thu, Aug 11, 2016 at 3:11 PM, Misra, Deapesh <dmisra () verisign com> wrote:
> > Hi,
> >
> > ------------------
> > - Background -
> > ------------------
> >
> > Here at iDefense, Verisign Inc, we have a Vulnerability Contributor
> > Program (VCP) where we buy vulnerabilities.
> >
> > Recently, security researcher Dawid Golunski sold us an interesting
> > vulnerability within Wget. We asked Red Hat (secalert at redhat dot com)
> > if
> > they would help us with the co-ordination (patching, disclosure, etc) of
> > this vulnerability. Once they graciously accepted, we discussed the
> > vulnerability with them. After their initial triage, Red Hat recommended
> > that we publicly post the details of this vulnerability to this mailing
> > list for further discussion and hence this email.
>
> That would have been me =).
>
> > It is very easy for an attacker to win this race as the file only gets
> > deleted after the HTTP connection is terminated. He can therefore keep the
> > connection open as long as necessary to make use of the uploaded file.
> > Below is proof of concept exploit that demonstrates this technique.
>
> Please note that the attacker would also have to have access to the local
> file system, either shell access or by some additional exploit,
> additionally they would have to have read access to the file wget is
> downloading (so same security context, or really poor permissions).
>
> > it is evident that the accept/reject rule is applied only after the
> > download. This seems to be a design decision which has a security aspect
> > to
> > it. As discussed above,
>
> It has to be. a PHP script can serve any file type for example. To filter
> on the URI is not what is being asked, the downloaded file is what is being
> filtered.
>
> >    - an attacker can ensure that the files which were not meant to be
> >
> > downloaded are downloaded to the location on the victim server (which
> > should be a publicly accessible location)
> >
> >    - the attacker can keep the connection open, even if the file/s have
> >
> > been downloaded on the victim server
> >
> >    - the attacker can then access these files OR use them in a separate
> >
> > attack
> >
> >    - the victim server's security is impacted since the
> >
> > developer/administrator was never warned explicitly that 'rejected files'
> > can have a transient life on the victim server
> >
> >
> > It looks like the design for wget needs to be changed so that the file it
> > downloads to 'recursively search' through is not saved in a location which
> > is accessible by the attacker. Additionally the documentation needs to be
> > enhanced with the explicit mention of the 'transient nature' of the files
> > which are to be rejected.
>
> This is easily accomplished using a safe umask for the file.
>
> Please note again that to exploit this you would need a situation where the
> attacker can control what wget is fetching, or execute a man in the middle
> attack, AND has local access to the system downloading the file AND has
> permissions to read the file AND some sort of additional vulnerability that
> requires being able to read a file in order to escalate privileges.

If the attacker has local access AND controls a server, he can call wget 
directly on most systems !? You mean, he wants to infect another user and 
needs a script file and/or executable downloaded by this user... how does the 
attacker convince the user to connect to his server with wget using -nH ?

If we take all the above as given, there are many more attack vectors using 
wget with different options.
Also, if the victim accidentally uses -nH in a directory of (ld-loadable) 
plugins or scripts... regularly checked and loaded/executed by some daemons or 
tools.

The only special thing I see in your report is the use of -A '*.jpg'. The 
victim could simply rely on no other files as *.jpg' ever appear in the file 
system. This wrong assumption can definitely lead to havoc - and the victim 
would claim wget being responsible. I can follow that argument.

Despite from this there are many ways to shoot oneself into the foot by using 
wget without thinking first (or just accidentally). Just think of --trust-
server-names, -O, -c, ..., e.g. downloading a ~/.bash_aliases (being executed 
the next time you log in).

> Wget is simply doing exactly what is asked of it, downloading files, and
> once downloaded checking if you wanted to keep them or not. Same as any
> HTTP(S) library that has a mirror function and filter function.
>
> We welcome your comments/suggestions.

We addressed this issue in wget2 - files just needed for parsing are kept in 
memory and never appear in the file system.
To fundamentally change the old wget's behavior, big parts have to be 
rewritten... well, that is what we did for wget2.

Maybe you could send your proof of concept via PM to the wget maintainers 
(Giuseppe Scrivano <gscrivano () gnu org>, darshit shah <darnir () gmail com>, Tim 
Rühsen <tim.ruehsen () gmx de>). So we have a test case and can perhaps develop a 
fix or counter measure.
Or do you think read+write just for the user are a reasonable fix ?

Regards, Tim

Attachment: signature.asc
Description: This is a digitally signed message part.