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

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

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

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