fetch extension - use local filename from
content-dispositionheader (new diff)
cracauer at cons.org
Fri Dec 30 11:28:50 PST 2005
Colin Percival wrote on Fri, Dec 30, 2005 at 10:47:46AM -0800:
> Martin Cracauer wrote:
> > Diff on
> > http:/www.cons.org/tmp/freebsd-fetch-O2.diff
> > When discussing, keep in mind that the user has to explicity give the
> > -O option (there is no environment variable to permanently turn this
> > on) and that the implications of the -O options are very clear and
> > simple. And that the main use of this is for folks who have to go
> > through a gazillion of Bugzilla attachments all name
> > "customer-errlog.20051220" etc, and there is no other way to download
> > them in a name-preserving manner than interactively opening them in
> > Mozilla and saving them.
> > Before we randomize the list even more I would say I'd like to hear
> > from the security officer if there is concern left.
> Ask and ye shall receive. :-)
> I must say that I still have some concerns about this. In general,
> creating a file with a server-specified name is a very easy way to
> open up security problems; aside from the already-mentioned problems
> of overwriting important system files or creating dot-files, I can
> very easily imagine a script which calls fetch(1) being in the current
> directory and being overwritten maliciously.
As noted no changing of directories and I kill filenames with dots at
the beginning, not to mention the option is off by default.
How is an attacker going to figure out what the script on your side is
named, if any? In any case, the nature of this option implies directly
and in a non-surprising manner this threat to files in the local
directory. Since this option is off by default and the user can only
find it in the manpage I don't see the "ooops" opportunity here.
Maybe a fat warning in the manpage?
> I also wonder why having an option for fetch(1) to create files with
> server-specified names is necessary. It seems to me that the best way
> to provide the functionality you want is to add a "-H headername"
> option which instructs fetch(1) to print out the value (if any) of the
> "headername" HTTP header. Then you could have a script download the
> file you want to a safe location, look at the Content-Disposition
> header, sanity-check it, and rename the file as appropriate.
Good point. Putting a script around it like that is no different than
instructing my version of fetch to do a sanity check on the name and
do it directly. Except more work, more bugs, and you need to manually
find out the name of the default savefile in first place.
You see, people who don't want or need this are not affected by this
feature in fetch. For people who need it, the integrated solution is
safer than a 30-second script, the root of many security troubles.
Just for starters, it is not realistic to assume such a script would
check for slashes or 8-bit chars which when echoed by reconfigure your
xterm. The fetch patch does.
I still think people arguing against this are just lucky enough that
they never have to get larger amounts of files off a webserver using
generic script names in the URL and name files with
Content-Disposition. But it is becoming more and more popular -
Bugzilla, Web forum software, Image hosting services, it's everywhere.
And this is why clients like Mozilla implement it. In a way, using
the name of the php/cgi script which doesn't have anything to do with
the actual filename is the bogus thing to do, in particular since we
are not compatible with interactive clients.
The content-disposition header is a standard web feature that we have
no good reason to ignore (as long as we don't turn it on unless
directly user-requested). We are just advancing with web technology,
which partly moves from explicit naming in URLs to simpler (for them)
DES, can you be more specific in what way I break the API? As far as
libfetch is concerned, all I do is pass to the caller one more header
from the webserver, in the same manner as the other headers that are
already there. Libfetch takes no action as a result of that header
except for possible printing of warnings. The semantics to use the
header for saving are all in fetch the program, not libfetch.
Martin Cracauer <cracauer at cons.org> http://www.cons.org/cracauer/
FreeBSD - where you want to go, today. http://www.freebsd.org/
More information about the freebsd-current