Re: [Bug-wget] Incorrect perms if downloaded file exists in the local FS

[Micah Cowan]

On 03/14/2012 06:03 AM, Borja Ruiz-Castro wrote:
> This can lead to race-condition attacks and privilege scalation.
> 
> The new downloaded file must own to the user who exec the wget command.

This race condition exists for every program that writes to an existing
file, or any shell redirection. Over-engineering a solution to just one
case seems ill-conceived; better to be careful with all solutions that
create files.

The -O option is designed to work exactly like a shell redirection, and
there are cases where one may want to write to an existing file (or
named pipe, or "normal"-looking file on a fuse file system, etc...). If
it concerns you, consider adding the option --no-clobber to your wget
invocation.

Your confusion seems to be that -O is intended to create a "new
downloaded file", or to simply choose a new name for a retrieved file,
when in fact it is not - it just mimics redirection. Even if that
weren't the case, though, I don't think forcing no-clobber in all cases
- or worse, actively resetting ownership and permissions to match
current umode, just on the off-chance it exists (and inevitably ignoring
other "new-file" characteristics, such as file attributes, or whatever
else comes down the line) - would be the way to go here.

In short, using _any_ program as root, to write to files in /tmp (or
other such locations) that one then intends to execute afterward, is a
very poor idea, and I'd chalk the security vulnerability to PEBKAC.

(Of course, this is my opinion, and I do not maintain Wget, so you might
check if Giuseppe agrees with me ;) )

-mjc