fetch extension - use local
filename from content-dispositionheader
Maxim Sobolev
sobomax at portaone.com
Thu Dec 29 20:04:31 PST 2005
I doubt that forbidding / is helpful, since attacker can put excessive
amount of ../ to reach / in most cases anyway:
sobomax at notebook$ pwd
/home/sobomax
sobomax at notebook$ ls -l ../../../../../../../../sbin/init
-r-x------ 1 root wheel 491364 21 ноя 14:48
../../../../../../../../sbin/init*
I think that more sensible policy would be allowing saving target file
into the current directory or any subdirectory below it, disallowing
writing files into any upper-level directories. This should be quite
easy to do using realpath(3).
sobomax at notebook$ realpath ././.././../.././../../../../../sbin/init
/sbin/init
-Maxim
Sean Bryant wrote:
> 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.
> _______________________________________________
> 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"
>
More information about the freebsd-current
mailing list