Re: fetch extension - use local filename from content-disposition header

From: Martin Cracauer <cracauer_at_cons.org>
Date: Thu, 29 Dec 2005 22:15:00 -0500
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.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer_at_cons.org>   http://www.cons.org/cracauer/
FreeBSD - where you want to go, today.      http://www.freebsd.org/
Received on Fri Dec 30 2005 - 02:15:07 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:49 UTC