Re: fetch extension - use local filename from content-dispositionheader

From: Sean Bryant <sean_at_cyberwang.net>
Date: Thu, 29 Dec 2005 22:36:55 -0500
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.
Received on Fri Dec 30 2005 - 02:40:40 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:49 UTC