I didn't want to randomize the list with a flood of mail, but I suppose any security discussion is good. Anyway, hopefully this will make it clear: > > The security implications are about the same as for the base > > functionality. Any filename in the current directory can be wiped out > > if you fetch or wget and a URL redirects to another URL which leads to > > a filename that matches. > > If fetch uses a redirected name as its local filename it is seriously > broken and must be fixed. The manpage does not mention it. OK, I just checked. It seems FreeBSD fetch does not do that, sorry. FreeBSD keeps the filename derived from the user-given URL, but wget does, it derives a new filename from the target of the relocation. Well, there's a reason why I want to use fetch, not wget. Anyway, since this option has to be given by the user on every invocation, and since there is no other way to get the desired functionality and since the behavior is non-suprisiving I'd still go forward. I am sure anybody who gets lots of customer bug reports in Mozilla attachments will be thankful. > > I will forbit "/" to appear in the suggested filename, though. > > Remember that the check must be made after any decoding of %xx et al. > But no check will save the gullible from creating .shosts in $HOME or > overwriting .profile . Let's say I forbit file name beginning with ".", too. That covers the obvious attack cases. 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 - 12:47:43 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:50 UTC