geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan (JIRA)" <j...@apache.org>
Subject [jira] Updated: (GERONIMO-3838) Close potential denial of service attack vector (OOM) in Tomcat session handling
Date Thu, 20 Nov 2008 05:18:44 GMT

     [ https://issues.apache.org/jira/browse/GERONIMO-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ivan updated GERONIMO-3838:
---------------------------

    Attachment: Geronimo-3838-11-19 For 2.0.patch

For WADI is not used in Geronimo-2.0, so it seems that no need to update the reference name
in the tomcatbuilder.
I create a patch file for changing the name back.
Thanks !

> Close potential denial of service attack vector (OOM) in Tomcat session handling
> --------------------------------------------------------------------------------
>
>                 Key: GERONIMO-3838
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-3838
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: Memory Leaks, security, Tomcat
>    Affects Versions: 2.0.2, 2.1.1
>         Environment: tested with JDK 1.5 running on Windows XP and FreeBSD6.2
>            Reporter: Radim Kolar
>            Assignee: Donald Woods
>            Priority: Critical
>             Fix For: 2.0.3, 2.1.4, 2.2
>
>         Attachments: Geronimo-3838-11-16.patch, Geronimo-3838-11-19 For 2.0.patch
>
>
> There is memory leak and it can be repeated very easily, so it should be very easy to
catch
> Install Geronimo and then run some kind of benchmarking software against its admin UI
login page, for example
> program ab from Apache HTTP. This is realistic attack scenario, because lot of denial
of service attacks are doing this (requesting one page many times).
> Watching memory used graph in admin console shows free memory slowly decreasing. After
all available memory is exhausted, application server stops serving new requests and never
restores ifself back to working state.
> I think that it is caused by allocating sessions without limiting total number of sessions
to keep in memory and possibly to swap sessions out to file. There needs to be user-configurable
setting for preventing this, it would be nice to add such setting to Admin console.
> Its very important to get this bug fixed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message