fetch extension - use local filename
from content-dispositionheader
Sean Bryant
sean at cyberwang.net
Thu Dec 29 19:40:40 PST 2005
Matt Emmerton wrote:
>>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
>
>_______________________________________________
>freebsd-current at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>
>
Well the programmer can only do so much, after that its up to the user.
Sanitize the filename before writing it. just escape troublesome
characters.
More information about the freebsd-current
mailing list