[Zope] Re: REMOTE_USER Security Issue

Tres Seaver tseaver at palladion.com
Tue May 16 10:21:04 EDT 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Pieters wrote:
> On 5/16/06, Cliff Ford <Cliff.Ford at ed.ac.uk> wrote:
> 
>> So I still wonder if anyone who is ising the REMOTE_USER environment
>> variable is aware of a problem and has a solution.
> 
> 
> Environment-related variables should not be "hackable" from restricted
> code. Please file a report in de Zope Collector:
> 
>  http://www.zope.org/Collectors/Zope
> 
> You'll need to log in (create a Zope.org account if you don't yet have
> one), and make sure you check the 'security related' tickbox.

Please *don't* mark the issue as "security related", as that only serves
to hide it:  the cat is already out of the bag here, anyway, assuming
that the hole is real:

  - The 'form', 'taintedform', 'cookies', and 'environ' attributes of
    an HTTPRequest are simple Python dicts, and can therefore be mutated
    by untrusted code.

  - It would be possible, although painful, to replace them by a
    derived class.  The pain will come from two axes:

    o Performance:  might not be too bad, depending on the
      implementation;  just using 'class MyDict(dict): pass'
      would be enough to prevent untrusted mutation.  We might
      have to add assertions which allowed '__getitem__' and the
      other accessors, however.  We could also use a "harder"
      implementation, which perhaps raised TypeError from all
      mutators.  I'm attaching a sample patch for the 'environ'
      dict.

    o Backward compatibility:  there may be third-party code which
      more-or-less legitimately expects to mutate one or more of
      those dicts.  We would thus probably have to add a zope.conf
      switch for the "hardening", and default it to the *current*
      setting.

Another solution would be to have the third-party code which suffers
from this flaw monkey-patch the HTTPRequest module to supply the needed
hardening.

Cliff, before we chase all this down, can you verify that the script
actually does allow access in your case?  I can imagine a case where the
authentication was already done by the time the script got to run, which
would make this an annoyance, rather than a hole.


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEad/Q+gerLs4ltQ4RAq6IAKDWRTIvxT9T1LUhVWkztHa0v4RUAgCbBc/b
2qRA0qkE0u46yaNVW4cH1aY=
=5Cnv
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: immutable_request_environ.patch
Type: text/x-patch
Size: 2907 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope/attachments/20060516/74597fbd/immutable_request_environ.bin


More information about the Zope mailing list