Re: [wmvs] OpenSP -R and Win32

On Mon, 6 Sep 2004, Bjoern Hoehrmann wrote:

> It is not clear to me what -R is trying to achieve and thus even less
> clear to me what the requirements would be for it when running on e.g.
> Cygwin, when compiled using MSVC++, or on NTFS systems. OpenSP will
> read only such files that the calling application tells it to read and
> those that constitute external parsed entities which means in order to
> exploit it the attacker would need to
[...]
>   * inject references to external parsed entities that resolve to
>     local resources through
>
>       * certain URI schemes like 'file'. OpenSP does not support
>         such schemes as far as I can tell.

OpenSP supports formal system identifiers such as "<OSFILE>/etc/passwd".

I suspect that "file" URIs would also work if SP_WININET were defined,
although -R doesn't help that situation.

[...]
>       * bugs in the calling application like
>
>           * HTTP resources as written to disk changing the base
>             URI to a 'file' one which then needs to be overridden
>             in order to properly resolve the external entity at
>             all.
>
> As this is something essential to resolve when working with other
> parsers, we should probably document our attack vectors somewhere to
> make sure users are aware of them, we do not forget about them and
> properly test attacks in our test suites. So are there any other
> threats relevant to -R that I have missed above? My understanding is
> that we use -R to workaround the last item, a bug in `check` which is
> essentially present because we cannot specify a proper base URI.

The last item and "<OSFILE>/etc/passwd" are the threats relevant to -R.

Being able to specify a proper base URI for OpenSP would be nice.  That
combined with restrictions on formal system identifiers like <OSFILE>
could be used as an alternative to -R.

> If I remember correctly, the problem with -R on Win32 is
>
>   As a further security precaution, this option limits filenames to
>   the characters A-Z, a-z, 0-9, '/', '.', '_', '-' and does not allow
>   filenames containing "..".
>
> I think it is possible to make -R work on Win32 if it is ensured that
> all relevant files can be reached using the same logical hard drive
> letter (so you can use relative paths) and these are referenced using
> "/" rather than "\" to separate path components. In order to make this
> behave more properly PosixStorageManager::isSafe(...) would need to
> allow at least the characters ':' and '\' in paths and it might be
> neccessary to change the comparison code so that c:\x and c:/x are
> considered a match. Under certain conditions of course. That might be
> #ifdef WIN32, #ifdef _MSC_VER, etc.

Your suggestion for improving isSafe() sounds reasonable to me.

-- 
Liam Quinn

Received on Monday, 6 September 2004 23:09:18 UTC