See how zope compares to other vendors in security performance
The DTML implementation in the Z Object Publishing Environment (Zope) allows remote attackers to conduct unauthorized activities.
Impact
RestrictedPython does not check access to stack frames and their attributes. Stack frames are accessible within at least generators and generator expressions, which are allowed inside RestrictedPython. An attacker with access to a RestrictedPython environment can write code that gets the current stack frame in a generator and then walk the stack all the way beyond the RestrictedPython invocation boundary, thus breaking out of the restricted scope allowing the call of unrestricted Python code and therefore potentially allowing arbitrary code execution in the Python interpreter.
All RestrictedPython deployments that allow untrusted users to write Python code in the RestrictedPython environment are at risk. In terms of Zope and Plone, this would mean deployments where the administrator allows untrusted users to create and/or edit objects of type Script (Python), DTML Method, DTML Document or Zope Page Template. This is a non-default configuration and likely to be extremely rare.
Patches
The problem has been fixed in releases 5.3 and 6.1.
Workarounds
There is no workaround available. If you cannot upgrade to the latest release you should ensure the RestrictedPython environment is only available for trusted users.
References
- RestrictedPython security advisory GHSA-wqc8-x2pr-7jqh
For more information
If you have any questions or comments about this advisory:
- Open an issue in the RestrictedPython issue tracker - Email us at security@plone.org
Credits
Thanks for analysing and reporting the go to: - Nakul Choudhary (Quasar0147 on GitHub) - despawningbone on GitHub - Robert Xiao (nneonneo on GitHub)
Impact The vulnerability allows unauthenticated execution of arbitrary SQL statements on the database the SQLAlchemyDA instance is connected to. All users are affected.
Patches The problem has been patched in version 2.2.
Workarounds There is no workaround. All users are urged to upgrade to version 2.2
Unspecified vulnerability in the Zope Enterprise Objects (ZEO) storage-server functionality in Zope Object Database (ZODB) 3.8 before 3.8.3 and 3.9.x before 3.9.0c2, when certain ZEO database sharing and blob support are enabled, allows remote authenticated users to read or delete arbitrary files via unknown vectors.
Unspecified vulnerability in Zope Object Database (ZODB) before 3.8.2, when certain Zope Enterprise Objects (ZEO) database sharing is enabled, allows remote attackers to execute arbitrary Python code via vectors involving the ZEO network protocol.
Plone upstream has published a pre-announcement about a security flaw, present in Zope v2.12.x and Zope v2.13.x, which could allow execution of arbitrary code by anonymous users. An authenticated attacker could provide a specially-crafted web page, which once visited by an unsuspecting Zope user would lead to arbitrary commands execution with the privileges of the Zope/Plone service.
References: [1] http://plone.org/products/plone/security/advisories/20110928 [2] http://secunia.com/advisories/46221/
Note: The vendor announced the final version of the advisory and the patch to be available at 2011-10-04 15:00 UTC at the following location: [3] http://plone.org/products/plone/security/advisories/20110928
Multiple cross-site request forgery (CSRF) vulnerabilities in Zope Management Interface 4.3.7 and earlier, and Plone before 5.x.
Impact Most Python modules are not available for using in TAL expressions that you can add through-the-web, for example in Zope Page Templates. This restriction avoids file system access, for example via the 'os' module. But some of the untrusted modules are available indirectly through Python modules that are available for direct use.
By default, you need to have the Manager role to add or edit Zope Page Templates through the web. Only sites that allow untrusted users to add/edit Zope Page Templates through the web are at risk.
Patches The problem has been fixed in Zope 5.2 and 4.6.
Workarounds A site administrator can restrict adding/editing Zope Page Templates through the web using the standard Zope user/role permission mechanisms. Untrusted users should not be assigned the Zope Manager role and adding/editing Zope Page Templates through the web should be restricted to trusted users only.
For more information If you have any questions or comments about this advisory: Open an issue in the Zope issue tracker Email us at security@plone.org
This advisory extends the previous advisory at https://github.com/zopefoundation/Zope/security/advisories/GHSA-5pr9-v234-jw36 with additional cases of TAL expression traversal vulnerabilities.
Impact Most Python modules are not available for using in TAL expressions that you can add through-the-web, for example in Zope Page Templates. This restriction avoids file system access, for example via the 'os' module. But some of the untrusted modules are available indirectly through Python modules that are available for direct use.
By default, you need to have the Manager role to add or edit Zope Page Templates through the web. Only sites that allow untrusted users to add/edit Zope Page Templates through the web are at risk.
Patches The problem has been fixed in Zope 5.21 and 4.6.1.
Workarounds The workaround is the same as for https://github.com/zopefoundation/Zope/security/advisories/GHSA-5pr9-v234-jw36: A site administrator can restrict adding/editing Zope Page Templates through the web using the standard Zope user/role permission mechanisms. Untrusted users should not be assigned the Zope Manager role and adding/editing Zope Page Templates through the web should be restricted to trusted users only.
References The previous advisory (GHSA-5pr9-v234-jw36)
For more information If you have any questions or comments about this advisory: Open an issue in the Zope issue tracker Email us at security@plone.org
Impact A user can gain access to protected (and potentially sensible) information indirectly via AttributeError.obj and the string module.
Patches The problem will be fixed in version 7.3.
Workarounds If the application does not require access to the module string, it can remove it from RestrictedPython.Utilities.utilitybuiltins or otherwise do not make it available in the restricted execution environment.
Impact Python's "format" functionality allows someone controlling the format string to "read" all objects accessible through recursive attribute lookup and subscription from objects he can access. This can lead to critical information disclosure. With RestrictedPython, the format functionality is available via the format and formatmap methods of str (and unicode) (accessed either via the class or its instances) and via string.Formatter. All known versions of RestrictedPython are vulnerable.
Patches The issue will be fixed in 5.4 and 6.2.
Workarounds There are no workarounds to fix the issue without upgrading.
References https://docs.python.org/3/library/stdtypes.html#str.formatmap http://lucumr.pocoo.org/2016/12/29/careful-with-str-format/ https://www.exploit-db.com/exploits/51580
For more information
If you have any questions or comments about this advisory:
Open an issue in the RestrictedPython issue tracker Email us at security@plone.org
Credits
Thanks for analysing and reporting the go to:
Abhishek Govindarasu Ankush Menat Ward Theunisse
Grok 7.6.6 through 9.2.0 has a heap-based buffer overflow in grk::FileFormatDecompress::applypaletteclr (called from grk::FileFormatDecompress::applyColour).
Impact Python's "format" functionality allows someone controlling the format string to "read" objects accessible (recursively) via attribute access and subscription from accessible objects. Those attribute accesses and subscriptions use Python's full blown getattr and getitem, not the policy restricted AccessControl variants getattr and getitem. This can lead to critical information disclosure.
AccessControl already provides a safe variant for str.format and denies access to string.Formatter. However, str.formatmap is still unsafe.
Affected are all users who allow untrusted users to create AccessControl controlled Python code and execute it.
Patches A fix will be introduced in the versions 4.4, 5.8 and 6.2.
Workarounds There are no workarounds.
References https://github.com/zopefoundation/RestrictedPython/security/advisories/GHSA-xjw2-6jm9-rf67 describes the corresponding problem for RestrictedPython.
Zope before 2.2.4 allows partially trusted users to bypass security controls for certain methods by accessing the methods through the fmt attribute of dtml-var tags.
Zope before 2.2.4 allows partially trusted users to bypass security controls for certain methods by accessing the methods through the fmt attribute of dtml-var tags.
Zope 2.2.0 through 2.2.4 does not properly perform security registration for legacy names of object constructors such as DTML method objects, which could allow attackers to perform unauthorized activities.
The DocumentTemplate package in Zope 2.2 and earlier allows a remote attacker to modify DTMLDocuments or DTMLMethods without authorization.
docutils in Zope 2.6, 2.7 before 2.7.8, and 2.8 before 2.8.2 allows remote attackers to include arbitrary files via include directives in RestructuredText functionality.
ZCatalog plug-in index support capability for Zope 2.4.0 through 2.5.1 allows anonymous users and untrusted code to bypass access restrictions and call arbitrary methods of catalog indexes.
Zope 2.2.0 through 2.5.1 does not properly verify the access for objects with proxy roles, which could allow some users to access documents in violation of the intended configuration.
AccessControl/AuthEncoding.py in Zope before 2.13.19, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote attackers to obtain passwords via vectors involving timing discrepancies in password validation.
A HTTP header injection flaw was found in the way Plone, a user friendly and powerful content management system, performed sanitization of HTTP headers provided within certain URL requests. A remote attacker could provide a specially-crafted URL that, when processed would lead the injected HTTP headers to be returned as part of Plone system HTTP response (possibly leading to HTTP response splitting, cross-site scripting [XSS] flaws, session fixation or unauthorized HTTP redirect attacks - to mention some of the possible negative consequences).
References: [1] http://plone.org/products/plone/security/advisories/20121106/02 [2] http://plone.org/products/plone/security/advisories/20121106/
Relevant upstream HotFixes: [3] http://plone.org/products/plone-hotfix/releases/20121106
From the OSS post: [4] http://www.openwall.com/lists/oss-security/2012/11/07/4
the setHeader.py change from upstream HotFix is relevant to this issue.
Zope before 2.13.19, as used in Plone before 4.2.3 and 4.3 before beta 1, does not reseed the pseudo-random number generator (PRNG), which makes it easier for remote attackers to guess the value via unspecified vectors. NOTE: this issue was SPLIT from CVE-2012-5508 due to different vulnerability types (ADT2).
It was reported [1] that Plone suffers from a vulnerability that can be exploited to bypass certain security restrictions. This is due to a vulnerable bundled version of Zope.
Plone 3.x users that backported the fix for CVE-2011-0720 (PloneHotfix20110720) are affected due to the vulnerability being inadvertently backported via the hotfix.
A new hotfix (20110622) is available [2] to correct the flaw.
[1] http://plone.org/products/plone/security/advisories/20110622 [2] http://plone.org/products/plone-hotfix/releases/20110622
ZServer in Zope 2.10.x before 2.10.12 and 2.11.x before 2.11.7 allows remote attackers to cause a denial of service (crash of worker threads) via vectors that trigger uncaught exceptions.
Zope Object Database (ZODB) before 3.8.2, when certain Zope Enterprise Objects (ZEO) database sharing is enabled, allows remote attackers to bypass authentication via vectors involving the ZEO network protocol.
Impact Background: The optional add-on package Products.PythonScripts adds Script (Python) to the list of content items a user can add to the Zope object database. Inside these scripts users can write Python code that is executed when rendered through the web. The code environment in these script objects is limited, it relies on the RestrictedPython package to provide a "safe" subset of Python instructions as well as the AccessControl package that defines security policies for execution in the context of a Zope application.
Recently the AccessControl package was updated to fix a remote code execution security issue. A link to the security advisory is provided in the References section below. The bug tightens the AccessControl security policies for Zope by blocking access to unsafe classes inside the Python string module.
You are only affected if the following are true:
- You use Python 3 for your Zope deployment (Zope 4 on Python 2 is not affected) - You run Zope 4 below version 4.6.3 or Zope 5 below version 5.3 - You have installed the optional Products.PythonScripts add-on package
By default, you need to have the admin-level Zope "Manager" role to add or edit Script (Python) objects through the web. Only sites that allow untrusted users to add/edit these scripts through the web - which would be a very unusual configuration to begin with - are at risk.
Patches The problem has been fixed in AccessControl versions 4.3 and 5.2. Zope releases 4.6.3 and 5.3 now require these new AccessControl releases.
Workarounds A site administrator can restrict adding/editing Script (Python) objects through the web using the standard Zope user/role permission mechanisms. Untrusted users should not be assigned the Zope Manager role and adding/editing these scripts through the web should be restricted to trusted users only. This is the default configuration in Zope.
References AccessControl security advisory GHSA-qcx9-j53g-ccgf
For more information If you have any questions or comments about this advisory: Open an issue in the Zope issue tracker Email us at security@plone.org
Impact The use of Python's marshal module to handle unchecked input in a public method on PortalFolder objects can lead to an unauthenticated denial of service and crash situation. The code in question is exposed by all portal software built on top of Products.CMFCore, such as Plone. All deployments are vulnerable.
Patches The code has been fixed in Products.CMFCore version 3.2.
Workarounds Users can make the affected decodeFolderFilter method unreachable by editing the PortalFolder.py module in Products.CMFCore by hand and then restarting Zope. Go to line 233 of PortalFolder.py and remove both the @security.public decorator for decodeFolderFilter as well as the method's entire docstring. This is safe because the method is not actually used by current code.
References - Products.CMFCore security advisory GHSA-4hpj-8rhv-9x87
Credits Thanks go to Nicolas VERDIER from onepoint.
For more information
If you have any questions or comments about this advisory:
- Open an issue in the Products.CMFCore issue tracker - Email us at security@plone.org
Zope before 2.2.4 does not properly compute local roles, which could allow users to bypass specified access restrictions and gain privileges.
Zope before 2.2.1 does not properly restrict access to the getRoles method, which allows users who can edit DTML to add or modify roles by modifying the roles list that is included in a request.