Whats the status of versions for 2.6.2 and 2.7? Have there been any decisions reached? I saw Jim's code get checked in but it won't stop the DoS I posted. -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue
Jamie Heilman wrote:
Whats the status of versions for 2.6.2 and 2.7? Have there been any decisions reached? I saw Jim's code get checked in but it won't stop the DoS I posted.
Say it a little louder. Here is what I think you're saying: - Anonymous users can still open a versioned database connection (although now they can't use it) - Merely opening a versioned connection consumes resources - Zope does not free those resources as it should Can you confirm that's what you're seeing? Either we need to make Zope free the resources, or if that's not possible, we need a different strategy. Shane
Shane Hathaway wrote:
Jamie Heilman wrote:
Whats the status of versions for 2.6.2 and 2.7? Have there been any decisions reached? I saw Jim's code get checked in but it won't stop the DoS I posted.
Say it a little louder. Here is what I think you're saying:
- Anonymous users can still open a versioned database connection (although now they can't use it)
- Merely opening a versioned connection consumes resources
- Zope does not free those resources as it should
Can you confirm that's what you're seeing? Either we need to make Zope free the resources, or if that's not possible, we need a different strategy.
If I may also add something else, it might be a good idea to limit the namespace where zope looks for a variable named "Zope-Version". Both ZApplication.py and the patch look for this variable in the whole REQUEST, (i.e. via request.get(...)). I'd propose to change that to REQUEST.cookies.get(...). As it is, it violates the principle of least surprise and is also a tad inconsistent, because the patch even assumes that the "Zope-Version" variable came via a cookie (it tries to delete said cookie). This is not purely aesthetical reasoning, since cookies can be trusted a bit more than other variables coming from the request. You can't inject them from third party sites, for instance. Limiting the lookup only to REQUEST.cookies would also make client side trojan attacks a bit harder (not that you can't do much worse things with these kinds of attacks). cheers, oliver
On Sunday 15 June 2003 08:11, Jamie Heilman wrote:
Whats the status of versions for 2.6.2 and 2.7? Have there been any decisions reached? I saw Jim's code get checked in but it won't stop the DoS I posted.
Ive not tested Jims code, but it looks to me like it *should* stop that attack. Have you tested it? -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
Brian Lloyd wrote:
Have you tested to ensure that the 2.6.2 (CVS) is still open to the DoS? If so, could you give me a quick scenario that I could use to reproduce it?
I haven't tested 2.6.2, I tested CVS HEAD, assuming the code change to both was the validated_hook in Zope/App/startup.py then 2.6.2 is vulnerable as well. The hacky bash script I posted earlier was the test I used, but you can test it just by going to a host running the latest code and appending ?Zope-Version=foo to the URL. If it creates a new, persistent, zodb connection in the version foo, then you can be had. The rule of thumb is: if an anonymous client can force an application server to store persistent data accross transactions, then the server will be vulnerable to a DoS attack. Shane Hathaway wrote:
- Anonymous users can still open a versioned database connection (although now they can't use it) - Merely opening a versioned connection consumes resources - Zope does not free those resources as it should
100% correct. Frankly I'm not entirely convinced anonymous users should ever be able to open a zodb connection, but I have no technical evidence to back that up, its just a hunch. Oliver Bleutgen wrote:
This is not purely aesthetical reasoning, since cookies can be trusted a bit more than other variables coming from the request. You can't inject them from third party sites, for instance.
Well actually you can inject them from 3rd party sites if the browser is IE, but that probably doesn't come as a surprise to anyone, IE is notoriously insecure. Toby Dickenson wrote:
Ive not tested Jims code, but it looks to me like it *should* stop that attack. Have you tested it?
Yes, you get a 401 now, but by that time the damage has been done. -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue
Jamie Heilman wrote:
100% correct. Frankly I'm not entirely convinced anonymous users should ever be able to open a zodb connection,
Well, without that, they would never be able to view a page from a Zope site. That would make it tricky to log in ;-) Chris
Chris Withers wrote:
Jamie Heilman wrote:
100% correct. Frankly I'm not entirely convinced anonymous users should ever be able to open a zodb connection,
Well, without that, they would never be able to view a page from a Zope site. That would make it tricky to log in ;-)
By which I ment being assigned pre-allocated resources vs. allocating the resource during the request itself. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer
Jamie Heilman wrote:
Chris Withers wrote:
Jamie Heilman wrote:
100% correct. Frankly I'm not entirely convinced anonymous users should ever be able to open a zodb connection,
Well, without that, they would never be able to view a page from a Zope site. That would make it tricky to log in ;-)
By which I ment being assigned pre-allocated resources vs. allocating the resource during the request itself.
I don't quite understand the nature of this DOS attack after the patch. You do requests with REQUEST['Zope-Versiom'] == <big string>. If I understand your code correctly (it was bash and perl afterall ;)) you create version i with a version name str(i)*500000. It seems (to me) that the sole cause for this DOS is that zope stores the version names in memory, that means you get a memory consumption for all version name strings of 10*500000 + 90*500000*2 which is 95.000.000 bytes, which is roughly the 90M you reported. But why does zope store the version names even if the transaction is aborted, isn't that another bug? cheers, oliver
On Tuesday 17 June 2003 09:01, Oliver Bleutgen wrote:
I don't quite understand the nature of this DOS attack after the patch. You do requests with REQUEST['Zope-Versiom'] == <big string>. If I understand your code correctly (it was bash and perl afterall ;)) you create version i with a version name str(i)*500000. It seems (to me) that the sole cause for this DOS is that zope stores the version names in memory, that means you get a memory consumption for all version name strings of 10*500000 + 90*500000*2 which is 95.000.000 bytes, which is roughly the 90M you reported.
The connection cache will also store a cached connection for each version. The connection is opened to *read* from the storage; no writes are needed. A more 'efficient' attack would be to use a tiny (but unique) Zope-Version string to request a page that loads alot of zodb objects into the connection cache, for example as a seach page. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
Shane Hathaway wrote:
- Anonymous users can still open a versioned database connection (although now they can't use it) - Merely opening a versioned connection consumes resources - Zope does not free those resources as it should
Then, we should fix the latter issue. Dieter
participants (6)
-
Chris Withers -
Dieter Maurer -
Jamie Heilman -
Oliver Bleutgen -
Shane Hathaway -
Toby Dickenson