Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)

On 13 Mar 2009, at 15:50, Frederick Hirsch wrote:

> Thanks for your review, I have some comments inline. Thomas, can you  
> please review
> my proposed change to the security considerations text Mark mentioned?


I believe that you mean this piece of text:

>> "Implementations that store the content of widget archives to the  
>> file
>> system during signature verification MUST NOT trust any path  
>> components
>> of file names present in the archive, to avoid overwriting of  
>> arbitrary
>> files during signature verification."
>>
>
>
>> {Comment] I don't understand this sentence - which may well be a  
>> problem
>> with my understanding rather than the sentence - please can you
>> enlighten me, thanks.
>
> I think this is better worded as:
>
> Implementations MUST NOT overwrite <widget files> during signature  
> verification, as this could open the possibility of an attack based  
> on substituting content for files due to malformed ds:Reference URIs  
> in a signature that has been replaced.
>
> (Thomas, can you please verify that I got that right?)

The basic attack that this piece of the text is about is unpacking a  
zip archive into the file system, trusting path components, and ending  
up overwriting arbitrary system files, because the zip file contained  
'../../../../etc/passwd'.  (Yes, I'm painting with an extremely broad  
brush here.)

Two points:

1. This should go into the security considerations, and probably  
shouldn't be phrased as normative text.

2. I agree with Mark that it's probably too confusing; I fear that  
your proposed replacement doesn't capture everything.

I'd suggest this instead:

> Implementations should be careful about trusting path components  
> found in the zip archive:  Such path components might be interpreted  
> by operating systems as pointing at security critical files outside  
> the widget environment proper, and naive unpacking of widget  
> archives into the file system might lead to undesirable and security  
> relevant effects, e.g., overwriting of startup or system files.

What do you think?

Received on Monday, 16 March 2009 11:18:12 UTC