Anonymous arbitrary shell execution possible via URL

[Alan Hoey]

The application root object has a p_ attribute, which is a reference to the OFS.misc_.p_ class. This class is used to define a bunch of static resources (icons, "Powered by Zope" banners etc). In order to compute the correct paths for the images, some modules are imported to allow access to their __file__ attribute. The webdav module, which is imported to locate the davlock.gif image has a docstring and is thus publishable.

It's possible to get from the webdav module to os (webdav/xmltools/minidom/xml/sax/saxutils/os), which allows among other things shell execution via the various popen methods.

Note that not all methods are publishable (eg os.system), as Zope is unable to enumerate the parameters required. I've tested this on 2.12 and 2.10, it appears 2.10 is not vulnerable as it always attempts to wrap objects when publishing (ie objects without an __of__ method can never be published)

Simple example:
http://localhost:14000/p_/webdav/xmltools/minidom/xml/sax/saxutils/os/popen2?cmd=touch%20hello.txt

[Christian Theune (ctheune)]

Hmm. Nobody picking this up? I can try to take a stab at this but probably not in this week.

[Tres Seaver (tseaver)]

I will check this out today.

[Tres Seaver (tseaver)]

I have verified that the following branches do not expose the webdav module:

- 2.8

- 2.9

- 2.10

- 2.11

[Tres Seaver (tseaver)]

This bug was introduced on the 2.12 branch in r114796:

  r114796 | hannosch | 2010-07-16 15:01:27 -0400 (Fri, 16 Jul 2010) | 2 lines

  Fixed deprecation warnings in OFS.misc_

The bug is that a number of modules are imported at class scope in order
to compute paths on disk to images. I can't see any reason not to move those
imports up to module scope, which would remove the attack vector.

The attached patch against the 2.12 branch makes the reported URL result
in a 404 (as desired).

[Tres Seaver (tseaver)]

The attached hotfix product initialization code removes all
modules from the dict of the 'p_' class: a previously vulnerable
2.12 instance is not vulnerable with this product installed.

[Tres Seaver (tseaver)]

The attached patch is against the 2.13 branch.

The trunk is not vulnerable, because it does not import 'webdav' to
find its image.

[Tres Seaver (tseaver)]

Affected versions:

 - Zope 2.12.10 - 2.12.19

- Zope 2.13.0a3 - 2.13.9

[Hanno Schlichting (hannosch)]

Tres, thanks a lot for the work!

Since this is such a serious vulnerability, the Plone security team would like to hold of the hotfix release a bit and do a pre-announcement. So all vendors get a chance to plan and prepare for deploying the hotfix.

We'll do a pre-announcement of the upcoming patch, to be released on Tuesday October 4. And then we can handle the actual release of the code on that day. I can take care of the Zope-side of the hotfix release and also release proper new versions of Zope 2.12 and 2.13 at the same time.

[Tres Seaver (tseaver)]

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

On 09/22/2011 04:24 AM, Hanno Schlichting wrote:

> Tres, thanks a lot for the work!
>
> Since this is such a serious vulnerability, the Plone security team
> would like to hold of the hotfix release a bit and do a pre-
> announcement. So all vendors get a chance to plan and prepare for
> deploying the hotfix.

That is exactly the reason *not* to hold off -- we should be putting out
the hotfix and new releases ASAP, because of it seriousness.

> We'll do a pre-announcement of the upcoming patch, to be released on
> Tuesday October 4. And then we can handle the actual release of the
> code on that day. I can take care of the Zope-side of the hotfix
> release and also release proper new versions of Zope 2.12 and 2.13 at
> the same time.

You want to leave this unpatched for *two weeks*? That seem grossly
irresponsible to me: the Zope community *is* bigger than a set of
nervous Plone integrators, and deserves to get fixes for "zero day"
exploits out as soon as they are availble.

Tres.
- --
===================================================================
Tres Seaver [phone] <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk57ZmIACgkQ+gerLs4ltQ5xKQCgs6UC9cxyAGmVOxU2AyK8Vcqv
bwMAoLPsPjyfORyUnvqhEM63lJv7xJ/U
=k919
-----END PGP SIGNATURE-----

[Martijn Pieters (mjpieters)]

On Sep 22, 2011, at 18:46 , Tres Seaver wrote:
>> Tres, thanks a lot for the work!
>>
>> Since this is such a serious vulnerability, the Plone security team
>> would like to hold of the hotfix release a bit and do a pre-
>> announcement. So all vendors get a chance to plan and prepare for
>> deploying the hotfix.
>
> That is exactly the reason *not* to hold off -- we should be putting out
> the hotfix and new releases ASAP, because of it seriousness.
>
>> We'll do a pre-announcement of the upcoming patch, to be released on
>> Tuesday October 4. And then we can handle the actual release of the
>> code on that day. I can take care of the Zope-side of the hotfix
>> release and also release proper new versions of Zope 2.12 and 2.13 at
>> the same time.
>
> You want to leave this unpatched for *two weeks*? That seem grossly
> irresponsible to me: the Zope community *is* bigger than a set of
> nervous Plone integrators, and deserves to get fixes for "zero day"
> exploits out as soon as they are availble.

This is *not* a "zero day". Alan is a member of the Plone security team, this bug has not been reported outside of the Zope bugtracker, and is thus not yet known outside of this privileged circle of Zope and Plone security team members. A "zero day" is a vulnerability that has been exploited before it is known to the vendor, this is not such a bug. Right now we have the luxury to formulate how we inform the community.

The Plone security team has had a lot of feedback about critical flaws like these. Enterprise customers especially like to be able to plan a critical security update well in advance (up to two weeks notice even); a one week notice is the current compromise. We would *not* communicate any details about the vulnerability, other than the versions affected and the level of seriousness, in the initial pre-announcement.

The alternative is to just throw the vulnerability and it's patch out there on a Tuesday. We will catch a large part of the community that is paying attention to security issues, but there is a much vaster group of Zope installations out there that remains vulnerable to this very exploit without immediate patching. We put those installations at risk the moment we issue the patch.

By pre-announcing, we can reach a much larger chunk of our audience as the message has time to spread out, *without* putting everyone at risk of the vulnerability being exploited early.

Martijn Pieters

[David Glick (davisagli)]

On 9/22/11 10:02 AM, Martijn Pieters wrote:
> On Sep 22, 2011, at 18:46 , Tres Seaver wrote:
>>> Tres, thanks a lot for the work!
>>>
>>> Since this is such a serious vulnerability, the Plone security team
>>> would like to hold of the hotfix release a bit and do a pre-
>>> announcement. So all vendors get a chance to plan and prepare for
>>> deploying the hotfix.
>> That is exactly the reason *not* to hold off -- we should be putting out
>> the hotfix and new releases ASAP, because of it seriousness.
>>
>>> We'll do a pre-announcement of the upcoming patch, to be released on
>>> Tuesday October 4. And then we can handle the actual release of the
>>> code on that day. I can take care of the Zope-side of the hotfix
>>> release and also release proper new versions of Zope 2.12 and 2.13 at
>>> the same time.
>> You want to leave this unpatched for *two weeks*? That seem grossly
>> irresponsible to me: the Zope community *is* bigger than a set of
>> nervous Plone integrators, and deserves to get fixes for "zero day"
>> exploits out as soon as they are availble.
> This is *not* a "zero day". Alan is a member of the Plone security team,
> this bug has not been reported outside of the Zope bugtracker, and is
> thus not yet known outside of this privileged circle of Zope and Plone
> security team members. A "zero day" is a vulnerability that has been
> exploited before it is known to the vendor, this is not such a bug.
> Right now we have the luxury to formulate how we inform the community.
>
> The Plone security team has had a lot of feedback about critical flaws
> like these. Enterprise customers especially like to be able to plan a
> critical security update well in advance (up to two weeks notice even);
> a one week notice is the current compromise. We would *not* communicate
> any details about the vulnerability, other than the versions affected
> and the level of seriousness, in the initial pre-announcement.
>
> The alternative is to just throw the vulnerability and it's patch out
> there on a Tuesday. We will catch a large part of the community that is
> paying attention to security issues, but there is a much vaster group of
> Zope installations out there that remains vulnerable to this very
> exploit without immediate patching. We put those installations at risk
> the moment we issue the patch.
>
> By pre-announcing, we can reach a much larger chunk of our audience as
> the message has time to spread out, *without* putting everyone at risk
> of the vulnerability being exploited early.
+1. In the case where we have the luxury of knowing about an issue that
has only been disclosed to us, it feels more irresponsible to me to
release it without (a non-specific) warning. A release with no
pre-announcement means more people will be unable to apply the patch in
a timely manner. I would be willing to compromise on a 1-week warning
period instead of 2 weeks.
David

[Matthew Wilkes (matthew-matthewwilkes)]

On 2011-09-22, at 1746, Tres Seaver wrote:

>
> You want to leave this unpatched for *two weeks*? That seem grossly
> irresponsible to me: the Zope community *is* bigger than a set of
> nervous Plone integrators, and deserves to get fixes for "zero day"
> exploits out as soon as they are availble.

Of course, and when they're available doesn't mean when they've just been implemented.

Leaving it un-patched for two weeks has three possible outcomes:

1) Someone else finds and starts exploiting this problem.
2) Someone else finds and reports this problem.
3) Nobody finds it.

If we release now the chances of #1 rocket to certain, whereas at the moment they're very low indeed. That's the point of doing these things in secret: so we have so breathing room!

I cannot believe that there are no important Zope sites that won't have someone looking for hot fixes 24 hours a day, 365 days a year. That's utter madness. Hell, even personal sites, this is an important fix, it compromises servers, it is grossly irresponsible to release without any warning.

Matthew

[Martijn Pieters (mjpieters)]

On Sep 22, 2011, at 20:20 , Tres Seaver wrote:
>> This is *not* a "zero day". Alan is a member of the Plone security
>> team, this bug has not been reported outside of the Zope bugtracker,
>> and is thus not yet known outside of this privileged circle of Zope
>> and Plone security team members.
>
> That is an unfounded assertion. This bug is trivially exploitable via
> wget against a URL -- you have no data at all to suggest that it is not
> already being exploited.

I think you are confusing ease of exploitation with ease of discovery of the vulnerability here. The ease of the exploit is in my opinion actually an argument for a pre-announcement; the easier the bug is to exploit the more we need to put people on alert that they need to patch.

>> By pre-announcing, we can reach a much larger chunk of our audience
>> as the message has time to spread out, *without* putting everyone at
>> risk of the vulnerability being exploited early.
>
> The Organization for Internet Safety's "Guidelines for Security
> Vulnerability Reporting and Response" disagrees[1]:
>
> 8.1 Advance Notification
>
> This document does not address processes for notifying selected
> groups of users about vulnerabilities in advance of the general
> population. While such “pre-release notifications” are sometimes
> done, and in very well-controlled cases can be carried out
> effectively, they are not a recommended practice in the general case.
> To cite just two examples of why this is so, there is no
> industry-wide consensus regarding the selection criteria for advance
> notification; and such data, if leaked, could increase the risk to
> the general population.
>
>
> [1] http://www.oisafety.org/guidelines/secresp.html

This talks about notifying selected groups of users. We are not talking about letting selected customers, or highly valued contributors, or anyone else in early. We are talking about a message to everyone, along the lines of: we'll release an important fix on such and such a date, be ready. It's a severe one. Nothing more.

Martijn Pieters

[Tres Seaver (tseaver)]

While the likelihood of finding this exploit accidentally is fairly
low, the payoff could be quite high, and thus might warrant some
non-casual effort. For instance, I know of at least one major intelligence
agency running Zope / Plone, which would be a really juicy target for
various classes of determined attackers, for whom studying the codebase
to look for such holes would be perfectly within reason.

Note that actual exploits can go undetected for a *long time* if their
effects are subtle enough. This bug has been in the wild for over a year
now.

[Alexander Limi (limi)]

My experience from both Firefox (high visibility) and Plone/Zope (very low
visibility) over the years has indicated that there's rarely exploits in the
wild (with a few notable exceptions in the Firefox case), and exploits
generally show up a little after you announce the vulnerabilities. Both of
these code bases are pretty large, and require a lot of insider knowledge to
discover and exploit.

Immediately publishing a fix without giving people some time to be ready for
it is generally considered poor practice with software that takes time to
update (think browsers in enterprises or server-side frameworks).

The flipside is that there will often be people ready to write an exploit on
that same day if you publish it widely, but that happens eventually anyway.
By telling our "insiders" (and by that I mean the people that follow Plone
news, not some secret list of people), at least they can be ready when a fix
is released.

Longer-term, I'd love for Plone to have some sort of way to subscribe to
security hotfixes so that people in non-critical scenarios like blogs (vs.
enterprise deployments) could get these hotfixes automatically applied.

On Thu, Sep 22, 2011 at 2:34 PM, Tres Seaver <email address hidden> wrote:

> While the likelihood of finding this exploit accidentally is fairly
> low, the payoff could be quite high, and thus might warrant some
> non-casual effort. For instance, I know of at least one major intelligence
> agency running Zope / Plone, which would be a really juicy target for
> various classes of determined attackers, for whom studying the codebase
> to look for such holes would be perfectly within reason.
>
> Note that actual exploits can go undetected for a *long time* if their
> effects are subtle enough. This bug has been in the wild for over a year
> now.
>
> ** Changed in: zope2
> Importance: Undecided => Critical
>
> --
> You received this bug notification because you are a member of Zope
> Security Team, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/848807
>
> Title:
> Anonymous arbitrary shell execution possible via URL
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/zope2/+bug/848807/+subscriptions
>

--
Alex Limi · +limi <http://profiles.google.com/limi> · @limi · limi.net

[David Glick (davisagli)]

That intelligence agency's consultant is on the Plone security team and voiced his support for giving advance warning. In the case of the last critical Plone security hotfix that was released, if we had done it on the original schedule without warning, that consultant would have been on a plane and unable to apply the fix. Since we gave a warning, the consultant was able to arrange for another person to apply the fix as soon as it was released.

We have to weigh the risk of making an early announcement and having someone put forth special effort and finding the vulnerability before we release the fix, vs. the risk of releasing the fix without warning and having someone comprehend the meaning of the fix and exploit it before people patch their sites. To me both have the potential for embarrassing consequences, but the likelihood of the former is lower.

[Tres Seaver (tseaver)]

For future reference: I was worried that this issue exposed a
deeper problem in the Zope2 machinery, and so investigated.

- Recall that the Zope2 publisher does not check access during
  traversal (the "customers with customers" usecase).

- During traversal, the publisher does extract roles from each
  object, remembering only the last set seen (again, to satisfy
  "customers with customers").

- In the case of the attack through '/p_/webdav/...', the 'p_'
  object is a class object, which has the following security
  declaration::

    security.declareObjectProtected()

  That declaration sets 'p_.__roles__' to the None object.

- When validating access to the 'popen' function, the effective
  roles are those of 'p_.__roles__' (the most recent parent which
  had any roles at all). None grants access without any further
  checks.

My conclusion is that the publisher is behaving as designed here:
the programming error which opened the attack (importing 'webdav'
at class scope), combined with making the 'p_' class promiscuous,
form a combination which might easily have been intended, and
which Zope2 was designed to allow.

We should probably audit Zope2 and its installed dependencies for
uses of 'declareObjectPublic' and verify that no other such
mistaken combinations occur.

[Tres Seaver (tseaver)]

Here are the modules which use 'declareObjectPublic' in code::

  $ find src -name "*.py" | xargs grep -l declareObjectPublic
  src/OFS/misc_.py
  src/HelpSys/ObjectRef.py
  src/Products/Sessions/__init__.py
  src/Products/Sessions/BrowserIdManager.py
  src/Products/Sessions/SessionDataManager.py
  src/Products/Transience/TransientObject.py
  src/Products/Five/security.py

  $ find eggs -name "*.py" | xargs grep -l declareObjectPublic
  eggs/five.formlib-1.0.4-py2.6.egg/five/formlib/objectwidget.py

Classes can also get '__roles__' assigned as None via
'Products.Five.security.protectClass'. I hacked that method to
dump the names of such classes::

  Products.Five.metaclass.AbsoluteURL'>
  Products.Five.metaclass.OFSTraversableAbsoluteURL'>
  Products.Five.metaclass.RootAbsoluteURL'>
  Products.Five.metaclass.MenuAccessView'>
  Products.Five.metaclass.FormMacros'>
  Products.Five.metaclass.SimpleViewClass
   (from eggs/.../zope/app/form/browser/widget_macros.pt)
  Products.Five.metaclass.SimpleViewClass
   (from eggs/.../zope/app/form/browser/add.pt)
  Products.Five.metaclass.SimpleViewClass
   (from src/Products/Five/skin/five_template.pt)