| 2010-09-01 11:08:06 |
Patrick Gerken |
bug |
|
|
added bug |
| 2010-09-01 11:08:44 |
Patrick Gerken |
bug |
|
|
added subscriber Philip Bauer |
| 2010-09-01 11:13:09 |
Patrick Gerken |
description |
This has been observed with regular plone installations, but the root cause is in zope.
The easiest way to trigger this behaviour, is buildbot.
Create this buildout.cfg:
[buildout]
extends=http://svn.plone.org/svn/collective/buildout/plonetest/plone-3.3.5.cfg
Get yourself a copy of bootstrap.py and run buildout.
Start zope.
Create a zope site
add a page.
log out
as anonymous, create an url like this: http://yoursite/plone/new_page?came_from:list=123
This request will trigger an exception in the exception handling. The exception does not get caught anywhere, causing the thread to be killed.
Doing this four times, kills all threads, the zope process itself continues to run.
This problem does not occur with Zope 2.12. There The ZServer has a catchall exception handler that covers the issue.
I created a branch from the 2.10 branch:
svn+ssh://do3cc@svn.zope.org/repos/main/Zope/branches/do3cc_catchall
It contains the same changes as they happened in Zope 2.12. On retrying the above procedure, the user does not get any answer, but the thread also does not die.
I'll mark this issue as a security vulnerability because I want the bug to be private.
This bug was originally reported by somebody else. |
This has been observed with regular plone installations, but the root cause is in zope.
The easiest way to trigger this behaviour, is buildbot.
Create this buildout.cfg:
[buildout]
extends=http://svn.plone.org/svn/collective/buildout/plonetest/plone-3.3.5.cfg
Get yourself a copy of bootstrap.py and run buildout.
Start zope.
Create a plone site
add a page.
log out
as anonymous, create an url like this: http://yoursite/plone/new_page?came_from:list=123
This request will trigger an exception in the exception handling. The exception does not get caught anywhere, causing the thread to be killed.
Doing this four times, kills all threads, the zope process itself continues to run.
This problem does not occur with Zope 2.12. There The ZServer has a catchall exception handler that covers the issue.
I created a branch from the 2.10 branch:
svn+ssh://do3cc@svn.zope.org/repos/main/Zope/branches/do3cc_catchall
It contains the same changes as they happened in Zope 2.12. On retrying the above procedure, the user does not get any answer, but the thread also does not die.
I'll mark this issue as a security vulnerability because I want the bug to be private.
This bug was originally reported by somebody else.
|
|
| 2010-09-01 11:15:20 |
Christian Theune |
description |
This has been observed with regular plone installations, but the root cause is in zope.
The easiest way to trigger this behaviour, is buildbot.
Create this buildout.cfg:
[buildout]
extends=http://svn.plone.org/svn/collective/buildout/plonetest/plone-3.3.5.cfg
Get yourself a copy of bootstrap.py and run buildout.
Start zope.
Create a plone site
add a page.
log out
as anonymous, create an url like this: http://yoursite/plone/new_page?came_from:list=123
This request will trigger an exception in the exception handling. The exception does not get caught anywhere, causing the thread to be killed.
Doing this four times, kills all threads, the zope process itself continues to run.
This problem does not occur with Zope 2.12. There The ZServer has a catchall exception handler that covers the issue.
I created a branch from the 2.10 branch:
svn+ssh://do3cc@svn.zope.org/repos/main/Zope/branches/do3cc_catchall
It contains the same changes as they happened in Zope 2.12. On retrying the above procedure, the user does not get any answer, but the thread also does not die.
I'll mark this issue as a security vulnerability because I want the bug to be private.
This bug was originally reported by somebody else.
|
This has been observed with regular plone installations, but the root cause is in zope.
The easiest way to trigger this behaviour, is buildbot.
Create this buildout.cfg:
[buildout]
extends=http://svn.plone.org/svn/collective/buildout/plonetest/plone-3.3.5.cfg
Get yourself a copy of bootstrap.py and run buildout.
* Start Zope
* Create a new Plone site
* Add a new page
* Log out
* As anonymous, manuallz craft the following URL: http://yoursite/plone/new_page?came_from:list=123
This request will trigger an exception in the exception handling. The exception does not get caught anywhere, causing the thread to be killed.
Doing this four times, kills all threads, the zope process itself continues to run.
This problem does not occur with Zope 2.12. There The ZServer has a catchall exception handler that covers the issue.
I created a branch from the 2.10 branch:
svn+ssh://do3cc@svn.zope.org/repos/main/Zope/branches/do3cc_catchall
It contains the same changes as they happened in Zope 2.12. On retrying the above procedure, the user does not get any answer, but the thread also does not die.
I'll mark this issue as a security vulnerability because I want the bug to be private.
This bug was originally reported by somebody else.
|
|
| 2010-09-01 11:17:54 |
Patrick Gerken |
description |
This has been observed with regular plone installations, but the root cause is in zope.
The easiest way to trigger this behaviour, is buildbot.
Create this buildout.cfg:
[buildout]
extends=http://svn.plone.org/svn/collective/buildout/plonetest/plone-3.3.5.cfg
Get yourself a copy of bootstrap.py and run buildout.
* Start Zope
* Create a new Plone site
* Add a new page
* Log out
* As anonymous, manuallz craft the following URL: http://yoursite/plone/new_page?came_from:list=123
This request will trigger an exception in the exception handling. The exception does not get caught anywhere, causing the thread to be killed.
Doing this four times, kills all threads, the zope process itself continues to run.
This problem does not occur with Zope 2.12. There The ZServer has a catchall exception handler that covers the issue.
I created a branch from the 2.10 branch:
svn+ssh://do3cc@svn.zope.org/repos/main/Zope/branches/do3cc_catchall
It contains the same changes as they happened in Zope 2.12. On retrying the above procedure, the user does not get any answer, but the thread also does not die.
I'll mark this issue as a security vulnerability because I want the bug to be private.
This bug was originally reported by somebody else.
|
This has been observed with regular plone installations, but the root cause is in zope.
The easiest way to trigger this behaviour, is buildout.
Create this buildout.cfg:
[buildout]
extends=http://svn.plone.org/svn/collective/buildout/plonetest/plone-3.3.5.cfg
Get yourself a copy of bootstrap.py and run buildout.
* Start Zope
* Create a new Plone site
* Add a new page
* Log out
* As anonymous, manuallz craft the following URL: http://yoursite/plone/new_page?came_from:list=123
This request will trigger an exception in the exception handling. The exception does not get caught anywhere, causing the thread to be killed.
Doing this four times, kills all threads, the zope process itself continues to run.
This problem does not occur with Zope 2.12. There The ZServer has a catchall exception handler that covers the issue.
I created a branch from the 2.10 branch:
svn+ssh://do3cc@svn.zope.org/repos/main/Zope/branches/do3cc_catchall
It contains the same changes as they happened in Zope 2.12. On retrying the above procedure, the user does not get any answer, but the thread also does not die.
I'll mark this issue as a security vulnerability because I want the bug to be private.
This bug was originally reported by somebody else.
|
|
| 2010-09-01 11:21:29 |
Christian Theune |
description |
This has been observed with regular plone installations, but the root cause is in zope.
The easiest way to trigger this behaviour, is buildout.
Create this buildout.cfg:
[buildout]
extends=http://svn.plone.org/svn/collective/buildout/plonetest/plone-3.3.5.cfg
Get yourself a copy of bootstrap.py and run buildout.
* Start Zope
* Create a new Plone site
* Add a new page
* Log out
* As anonymous, manuallz craft the following URL: http://yoursite/plone/new_page?came_from:list=123
This request will trigger an exception in the exception handling. The exception does not get caught anywhere, causing the thread to be killed.
Doing this four times, kills all threads, the zope process itself continues to run.
This problem does not occur with Zope 2.12. There The ZServer has a catchall exception handler that covers the issue.
I created a branch from the 2.10 branch:
svn+ssh://do3cc@svn.zope.org/repos/main/Zope/branches/do3cc_catchall
It contains the same changes as they happened in Zope 2.12. On retrying the above procedure, the user does not get any answer, but the thread also does not die.
I'll mark this issue as a security vulnerability because I want the bug to be private.
This bug was originally reported by somebody else.
|
This has been observed with regular plone installations, but the root cause is in zope.
The easiest way to trigger this behaviour, is buildout.
Create this buildout.cfg:
[buildout]
extends=http://svn.plone.org/svn/collective/buildout/plonetest/plone-3.3.5.cfg
Get yourself a copy of bootstrap.py and run buildout.
* Start Zope
* Create a new Plone site
* Add a new page, make it private.
* Log out
* As anonymous, manually craft the following URL: http://yoursite/plone/new_page?came_from:list=123
As the page is private and can not be accessed by anonymous users a bug in the PAS code will trigger an exception. This exception does not get caught, causing the thread to be killed.
Doing this repeatedly allows one to kill all threads thus causing a denial of service. Note that the Zope process itself will continue to run.
This problem does not occur with Zope 2.12. There The ZServer has a catchall exception handler that covers the issue.
I created a branch from the 2.10 branch:
svn+ssh://do3cc@svn.zope.org/repos/main/Zope/branches/do3cc_catchall
It contains the same changes as they happened in Zope 2.12. On retrying the above procedure, the user does not get any answer, but the thread also does not die.
I'll mark this issue as a security vulnerability because I want the bug to be private.
This bug was originally reported by somebody else.
|
|
| 2010-09-01 12:00:40 |
Matthew Wilkes |
cve linked |
|
2010-3198 |
|
| 2010-09-01 12:24:08 |
Tres Seaver |
marked as duplicate |
|
373621 |
|
| 2010-09-01 12:33:04 |
Tres Seaver |
zope2: status |
New |
Confirmed |
|
| 2010-09-01 12:33:10 |
Tres Seaver |
zope2: importance |
Undecided |
Medium |
|
| 2010-09-01 12:33:16 |
Tres Seaver |
zope2: assignee |
|
Tres Seaver (tseaver) |
|
| 2010-09-01 12:34:09 |
Tres Seaver |
zope2: milestone |
|
2.10.12 |
|
| 2010-09-01 13:38:19 |
Tres Seaver |
zope2: status |
Confirmed |
Fix Committed |
|
| 2010-09-01 18:32:30 |
Tres Seaver |
zope2: status |
Fix Committed |
Fix Released |
|
| 2010-09-02 18:06:31 |
Tres Seaver |
visibility |
private |
public |
|
