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.
=====
This bug deals with an out of memory condition within Jserv which is
more a design/security issue. The scenario is that when a session is
created by a servlet; memory is allocated by the JVM for that session
and stays allocated until these two conditions occur 1) the servlet
invalidates the session or the session timeout is reached which
invalidates the session and 2) JVM garbage collection returns that
allocated memory back to the heap.
The reason this is a design/security issue is because any normal Java
Servlet application can be used for a denial of service attack. The
Java Servlet specification encourages applications to use sessions if
they wish to maintain state. A hacker can easily discover if any
application is a Java Servlet which uses sessions by checking to see if
the JSESSIONID cookie is defined; if the hacker finds one then a simple
program can be used to increase the memory usage on the server and crash
the JVM.
while (server is still up)
send an HTTP request to the servlet URL which creates the session
The timeout variable and the maximum java heap size are the only two
ways that the application can attempt to avoid this attack; by setting a
short timeout and a large heap size, one can hope that there is a
sufficient span to handle all of the requests (i.e. the timeout kicks in
before the memory has max'ed out). But there are problems with this:
* Set a timeout too short and normal users get their session invalidated
before they are able to complete normal usage of the application.
* Java heap size reserves memory which cannot be swapped out (on solaris
at least), so a large heap size puts a strain on the server's memory.
* The hacker can always deploy additional clients to generate more
concurrent requests.
=====
I have been writing stress tests for Jserv, Tomcat, and our own servlet
engine; when I brought this issue up with the developers here, I
essentially got my hand slapped (*sigh*) and told "application
developers must deal with this, it is not the servlet engines
responsibility". Which I think is a highly unfortunate answer because
HttpSession is a core servlet API and telling developers that they
cannot use it and should use an alternate mechansim, just seems wrong to
me. So, I figured I would post a message to this list for discussion.
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.
if (creating a new session)
{
session_count = 0
Loop through set of sessions for that client
{
/* Was this session created within the time period */
if ((current_date - creation_date_of_session) > time_period)
++session_count;
}
if ((session_count + 1) > num_of_sessions)
/* Good possibility we are being attacked */
else
/* create the new session */
}
=====
Presumably default values could be given to the num_of_session and
time_period parameters which still allow the problem user (somebody
opening up multiple browser windows, stoppng/starting browser, etc) to
gain access to the application, yet small enough to prevent the JVM from
consuming large amounts of memory before the attack is discovered. Once
an attack is discovered, the servlet engine could be proactive and
delete all of the sessions created by the client to free up the memory,
log messages, etc.
cheers
Scott
/* Thankfully Oracle doesn't speak for me, nor vice-versa */
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
