This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 771283 - (CVE-2011-5035) CVE-2011-5035 GlassFish: hash table collisions CPU usage DoS (oCERT-2011-003)
CVE-2011-5035 GlassFish: hash table collisions CPU usage DoS (oCERT-2011-003)
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20111228,repor...
: Security
Depends On:
Blocks: hashdos/oCERT-2011-003
  Show dependency treegraph
 
Reported: 2012-01-03 00:29 EST by David Jorm
Modified: 2015-07-31 02:47 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-03 00:34:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David Jorm 2012-01-03 00:29:10 EST
Julian Wälde and Alexander Klink reported a way to degrade performance of the Java HashMap and HashTable implementations by filling the hash table with keys with identical hash codes. See bug #750533 for details. This issue can be used to mount an efficient details of service attack against GlassFish application server. GlassFish parses HTTP request parameters and stores them in a hash table. A remote attacker could use this flaw to make the GlassFish java process use an excessive amount of CPU time by sending a POST request with a large number of parameters which hash to the same value.
Comment 1 David Jorm 2012-01-03 00:34:06 EST
Statement:

Not vulnerable. This issue affects the GlassFish Web Container component. This
component is not shipped with any Red Hat products. JBoss Web and Tomcat
provide the web container used in all JBoss products.
Comment 2 Tomas Hoger 2012-02-15 04:04:21 EST
Note that this CVE was also used for the HttpServer class in the standard Java Class Library, which did not limit the number of HTTP headers read from HTTP requests and stored in the HashMap, hence allowing the hash collision to be triggered.  That issue is tracked via separate bug #788606.

Note You need to log in before you can comment on or make changes to this bug.