Re: [wmvs] OpenSP -R and Win32

* Terje Bless wrote:
>>Win32 support is a good example, OpenSP makes it something between very
>>difficult and impossible to use -R on Win32

>We do need to figure out some way to make -R work on Win32 for the Validator
>to be able to work there. I see no way that we can justify running a CGI
>without -R, particularly on Win32 where all too many users run as local Admin.
>
>Do I take you looked at the relevant code and found it too `nix-centric to
>modify to support Win32?

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

  * compromise the server changing

      * check or its dependencies
      * one of the relevant SGML catalogs
      * one of the relevant DTDs

    if that happens, the attacker will most likely have sufficient
    privileges on the server to disable -R or work around it which
    means -R does not mitigate this problem

  * 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.

      * bugs in the 'http' resolver, for example it might consider
        http://www.example.org/../../foo to refer to file:///foo,
        -R would help is this unlikely case

      * a reference to a well-known local resource available through
        a supported scheme like http://intranet/

      * 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.

In IEQABar I took a different approach, it supports only a limited set
of document types and will modify each document overriding the probably
missing document type declaration by something well-known, If you have

  <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  "http://www.w3.org/TR/html401/loose.dtd" [
    <!ENTITY left SYSTEM "left"> ]>
  <title></title>
  <p align="&left;">...</p>

It will pass something like

  <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <title></title>
  <p align="&left;">...</p>

to OpenSP. This prohibes legal and illegal use of internal subsets as
both a problem and a feature as it prohibes doing stuff like

  <!ATTLIST img alt CDATA #IMPLIED>

in the internal subset and thus fake validation results. The primary
requirement was however to guarantee zero network traffic and validation
results (for document types with unknown non-retrievable DTDs or without
a document type declaration) and this is just a side-effect.

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.

Received on Monday, 6 September 2004 13:58:48 UTC