Scott Christley typed the following on 10:54 AM 1/17/2001 -0800
>I must apologize first by saying that I originally found this bug with
>Jserv not Tomcat, but those of you who are familiar with Tomcat
>internals can probably tell fairly quickly if this would still be an
>issue.
It could potentially be an issue, but can be controlled to some extent.
The PersistentManager class I have submitted for Tomcat 4 offers
a bit more control. I can offer a few comments on Tomcat 4 with and
without this class.
The nature of the possible attack, as I understand it, is that a bad guy
can make a rapid series of requests to the web app, causing the generation
of a large number of session objects thereby eating up available memory.
The current StandardSession implementation has a parameter called
maxActiveSessions which, if set (it's disabled by default), limits the number
of sessions which the server will create. A request which tries to create
any sessions after the limit is reached throws an IllegalStateException.
This isn't ideal for the user experience, but if it is set according to the
likely session memory usage and the heap size, it should occur just before
memory runs out, so it's better than the alternative.
PersistentManager, which would be an optional replacement for
StandardSession, allows you to have sessions swapped out of memory
(to a file or DB most likely) based on configurable parameters: idle time
and the number of active sessions. Sessions over a certain number would
be swapped out, as would sessions idle for a configurable time.
The caveat on this is that there is a danger of thrashing when the site
is very active - sessions could be constantly swapped in and out of memory,
exacerbating performance problems. So there is an option to set a minimum
idle time - sessions which are idle for less than this time won't be swapped
out even if there are more than maxActiveSessions in memory. This
effectively turns maxActiveSessions into a soft limit rather than a hard limit.
>I did have an idea for how this issue can be resolved; I've not totally
>thought it through, but it may be a good start.
>
>=====
>Given a parameter (num_of_sessions) which is the maximum number of new
>sessions.
>Given a parameter (time_period) which is a time interval.
>
>Implement a verification such that maximum number of new sessions that
>can be created from the same client within a time interval. This would
>require that you maintain a creation date and client identifier with
>each session.
As Tomas pointed out, identifying a client is problematic: the entire purpose
of using the cookie is to get around the difficulty in reliably identifying a client.
Perhaps this could be done on a system-wide level instead - limit the number
of new sessions created in a certain time period.
I tend to think that the PersistentManager options I outlined above can be used
to prevent this attack if configured correctly. maxActiveSessions can be
set as a hard limit to keep the active sessions to a number which can be
safely supported by the heap size. This doesn't prevent an attacker from
eating up most of the available sessions and creating a bad situation for
legitimate users, but it should avoid an outright system crash.
Kief
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
