Re: fetch extension - use local filename from content-dispositionheader

> Matt Emmerton wrote on Thu, Dec 29, 2005 at 10:09:03PM -0500:
> > > Sean Bryant wrote:
> > > > Barney Wolff wrote:
> > > >
> > > >> On Thu, Dec 29, 2005 at 07:33:38PM -0500, Martin Cracauer wrote:
> > > >>
> > > >>
> > > >>> I'm a bit rusty, so please point me to style mistakes in the
appended
> > > >>> diff.
> > > >>> The following diff implements a "-O" option to fetch(1), which,
when
> > > >>> set, will make fetch use a local filename supplied by the server
in a
> > > >>> Content-Disposition header.
> > > >>>
> > > >>
> > > >> Have you considered the security implications of this option?
> > > >>
> > > >>
> > > >>
> > > > Its just an extra option. I'm sure the details could be summed up in
the
> > > > man page.
> > >
> > > I think what Barney means is that if you run fetch(1) as root and the
> > > server returns the filename as "/sbin/init" bad things will happen.
> > > The data returned in Content-Disposition should be used with caution.
> >
> > Would checking to see if the target file exists, and if so, abort the
> > operation and display a warning be sufficient to address the security
> > issues?  Of course, we'd need some kind of "force" option to override
this
> > for the foot-shooting folks, and -f is already taken, but that could
easily
> > be documented as a "limitation" of this option.
>
> I don't like it since it derives too much from standard behavior which
> is to use a local name derived from the URL, even if it exists.
>
> Also, not overwriting files doesn't cut it for security, you could
> e.g. create a nonexisting .rhosts or .ssh/authorized_keys or play
> similar games.
>
> Forbidding "/" will set the security to the same level as the base
> functionality.  I like that.

Agreed, although it still leaves open all the security loopholes that were
mentioned, given the proper cwd and malicious intent on the server end.

--
Matt Emmerton