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) schemes. 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 -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 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 - 18:28:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:50 UTC