All Things WebSphere

Dear WebSphere Administrators,

Please patch your WAS deployments ASAP to fix a Denial of Service Security Exposure with Java JRE/JDK hanging when converting 2.2250738585072012e-308 number (CVE-2010-4476) (PM32387)
See http://www-01.ibm.com/support/docview.wss?uid=swg21462019#solution_dist
This vulnerability can cause the Java Runtime Environment to go into a hang, infinite loop, and/or crash resulting in a denial of service exposure. This same hang will occur if the number is written without scientific notation (324 decimal places). In addition to the Application Server being exposed to this attack, any Java program using the Double.parseDouble method is also at risk of this exposure including any customer written application or 3rd party written application.

The security vulnerability is generic and specifically its a bug in sun.misc.FloatingDecimal.doubleValue
 See http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/

This can be used as a denial of service attack against app servers, by sending the server an HTTP request containing this value in a field - if the server parses the value with parseDouble(), the thread doing the parsing will go into an infinite loop.

A hacker looks up a website and submits the string value "2.2250738585072012e-308" for a form field that expects double and parses it on the server side.  Other instances could  include an web service hosted on WAS  that take a string input from a form or a URL, and tries to convert said string to a floating point variable  Any code on the server side that does parseDouble is now compromised if hacker figures out how to trigger the parsing.

And remember ...
Oracle recently released a fix for the same
http://blogs.oracle.com/security/2011/02/security_alert_for_cve-2010-44.html
http://www.oracle.com/technetwork/topics/security/alert-cve-2010-4476-305811.html

A: Performance does not differ significantly between database persistence and memory-to-memory replication. This is because 95% of the cost of replicating or persisting sessions is incurred in the serialization/deserialization of the session object -- which must occur regardless of how the session is distributed. Also, as the size of the session object increases, performance degrades -- again, about equally for both session distribution options.

Instead, the decision will be based partially on how the two technologies differ: With a database, you actually persist the data (to disk), so a highly available database server can survive a cascading failure, while using application servers as session stores and replicators for this purpose may not. In the case of a "gold standard" (two identical cells/domains), a highly available database can pretty much assure session failover between domains, while with memory to memory, there can only be a single replicator common to the two cells; hence, it becomes a single point of failure (SPOF).

Thus, for configurations where cross-cell session failover is a requirement, a highly available database is the only option for eliminating a SPOF. Note that while sharing sessions across cells is supported, this is not generally recommended. By sharing state between cells, it makes it significantly more difficult to independently upgrade components (application and WAS) in the two cells. In the end, the decision then becomes based on what technology you are most comfortable with and which delivers the required quality of service for your availability requirements.

With memory-to-memory replication, the amount of session information you can store is bounded by the JVM heap size of your application server(s). Even with the advent of 64-bit JVM support in WebSphere Application Server V6.01, the maximum application server heap size is going to be significantly smaller than the amount of disk space you have available on a database server that is serving as a session store. Therefore, I am still of the opinion that database persistence remains the best option, although I know that in many organizations it is more expedient to use memory-to-memory replication to avoid conflicts over roles and responsibilities between system and database administrators.

A common cause of serious problems is the use/abuse of the HTTP session for all kinds of garbage. It all starts when one programmer decides to throw a little something in there, then another, and another, until your poor session looks like one of those polluted ponds filled with old tires and washing machines.
Stuffing something into the session is a very common shortcut taken under duress of an impending deadline. The effect on JVM heap sizes and performance (particularly when using persistent sessions) is dramatic. Doing code reviews (see #3) can help to prevent this. Session sizes should be from 2-4K, and there are several ways to measure them; the Tivoli® Performance Monitor that comes with WebSphere Application Server, for example, will show you session sizes.

Also read
1. Comment lines: Erik Burckart: What you want to know about HTTP session persistence     
2. Chapter 12 of WebSphere Application Server V7 Administration and Configuration Guide
   

From John Pape :  Use the Memory Analyer Tool (MAT) to diagnose problems in your Java applications