Re: [Bug-wget] Wget - acess list bypass / race condition PoC

[Tim Rühsen]

On Donnerstag, 18. August 2016 15:34:12 CEST Giuseppe Scrivano wrote:
> Hi,
> 
> Tim Rühsen <address@hidden> writes:
> > Please review / test this patch.
> > 
> > Please check the 'Reported-by' in the commit message and if you got a CVE
> > number, please report for inclusion into the commit message (and/or the
> > code).
> > 
> > Regards, Tim
> > 
> > On Mittwoch, 17. August 2016 10:40:35 CEST Dawid Golunski wrote:
> >> Random file name + .part extension on temporary files would already be
> >> good improvement (even if still stored within the same directory) and
> >> help prevent the exploitation.
> 
> I still think we should used a fixed extension, not a random file name.

You mean *only* a fixed extension without random part ?
With very long file names (length >= max length of supported by filesystem) we 
need a variant of the current file name shorten algorithm. IMO, this is 
unneeded code inflation.

> If wget crashes or the process is terminated for any reason, these files
> will be left around. 

Yes, but easy to see / find using 'wget_*.part' pattern.

> With a deterministic name, at least we can recover
> from what was left.

With -A/-R and --spider only (HTML | CSS) files are affected. Which are very 
seldom large enough that downloading again would hurt. 
With --recursive, all those files have to be redownloaded anyways.

We could use a simple 6 or 8 hex digit hash of the original file instead of the 
random part to have a deterministic file name. Is something like that what you 
think of ?

> IMO, it is enough to open these files with rw only for the user and not
> add any extra complexity.  It is not wget responsibility to take care of
> a misconfigured server that allows to execute random files fetched from
> http/ftp.

To cite myself :)
"But there is also non-obvious wget behavior in creating those (temp) files in 
the filesystem."

The Wget docs just don't make clear that these files come into existence for a 
while. Of course we could amend the docs and lean back... but it still is not 
an intuitive behavior and I fear people might trap into that pit. And we could 
easily prevent it with some lines of code...

Regards, Tim

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