On Thu, Mar 12, 2009 at 6:27 PM, Marcin Hanclik
<marcin.hanc...@access-company.com> wrote:
> Hi Mark,
>
>>>"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 assume it is as follows:
>
> 1. Imagine the WUA is processing a widget archive, i.e. a zip file where each
> file has its associate relative path.
>
> ZIP spec contains the following text:
>
> file name: (Variable)
>
> The name of the file, with optional relative path.
> The path stored should not contain a drive or
> device letter, or a leading slash.
> I.e. the path may be virtually any string.
Yep. Don't know if this helps, but in the packaging we define the
notion of a "file entry", which is essentially, the file name (path),
and the compressed data.
> 2. Prior to signature verification the archive is untrusted.
right. In the packaging spec, we call this a potential zip archive and
a potential widget archive, IIRC.
> 3. Next, let's assume WUA is configured to store the temporary files from the
> widget archive (storage may be necessary for devices with limited RAM) in a
> folder like C:/widgetplayer (e.g. on Win32/WinCE).
>
> 4. Then a file from a widget archive could have a path like "../windows/XXX".
>
> 5. As for me the text says that the path should be ignored when processing
> the signature to prevent WUA from storing the files e.g. in a sensitive
> folder like "c:/windows/" as it could be the case when combining the above
> paths.
>
This sounds like an implementation detail. A warning note to
implementers should be sufficient to address this.
--
Marcos Caceres
http://datadriven.com.au
