This JVM bug seems to be getting some high-level attention in the IT press so I thought I’d lay out the issue where CF is concerned:

History

The bug is in the JVM (it has been since ~2001) and so ColdFusion running on Sun JVMs are affected.
Someone out there has obviously made the link between the same issue happening in PHP and brought this issue to light again ( http://bugs.php.net/bug.php?id=53632 ). There’s a Java related discussion happening here: http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/

How to reproduce

To have the bug show, you must call the parseDouble() method of the java.lang.Double class. There are several ways this can happen. Many people are discussing this as a vulnerability that can be executed at the HTTP header level like so:

Accept-Language: en-us;q=2.2250738585072012e-308

However, this requires a call to HttpServletRequest’s getLocale() method, something that isn’t done trivially on a JRun4, CF 9.0.1 instance (even when calling the ColdFusion function “getLocale()”). Thus, to show this problem, you must do something like…

#GetPageContext().getRequest().getLocale()#

… within your ColdFusion page.

From our experience, a more likely attack could be performed with code like this:

<cfparam name="URL.pageNum" default="1" />
<cfparam name="URL.itemsPerPage" default="10" />
<cfquery name="qProducts" datasource="mysql_dsn">
    SELECT * FROM products
    LIMIT #((URL.pageNum-1) * URL.itemsPerPage) + 1# , #URL.pageNum * URL.itemsPerPage#
</cfquery>

The problem here is “URL.pageNum-1“. This calculation causes a call to parseDouble() behind the scenes which means that if the page were called with “page_name.cfm?pageNum=2.2250738585072012e-308” then the thread would hang in an infinite loop.

What doesn’t show the issue?

Note that in this example, “URL.itemsPerPage” could also cause the issue because it is used in the multiplication calculation. If the variable were not used in any calculations but only output, it would not show the issue. This example does NOT show the problem:

<cfset x = 2.2250738585072012e-308 />
<cfoutput>#x#</cfoutput>

What can you do?

Short term

If you have FusionReactor installed and configured with CrashProtection enabled and configured, the threads can be automatically killed by FusionReactor, saving your server from almost certain failure. To do this, enable Crash Protection and configure a “Request Timeout” value and set it to use the “Abort and Notify” strategy. This will cause requests taking longer than this time to quit – even if they are stuck in the infinite loop bug as in this scenario.

For those of you who are wondering, this is NOT the same as the ColdFusion timeout mechanism and so the ColdFusion page timeout alone will not help you in this scenario.

It’s good practice to have FusionReactor installed and Crash Protection enabled because it can save you from a lot of these issues without you needing to do anything.

Long term

I’m sure Oracle/Sun will offer a new update in due course. However, you can also download the “Java SE Floating Point Updater Tool”:
Download: http://www.oracle.com/technetwork/java/javase/downloads/index.html#fpupdater
Read Me: http://www.oracle.com/technetwork/java/javase/fpupdater-tool-readme-305936.html

Further Help

If you’re in need of help updating your JVM and/or patching it then we can offer assistance in this area from as little as $800. The FusionReactor product is available from as little as $249 and contains a wealth of other features – the majority of which are not covered by the ColdFusion Server Monitor – http://www.fusion-reactor.com/fr/ for more information.

Notes

This article refers to JRun4, CF9 installations. The issue is apparent on a wide variety of Java platforms (we offer consulting for most Java environments) and is more prevalent on Tomcat installations (which includes JBoss).

References

Official security alert (CVE-2010-4476): http://www.oracle.com/technetwork/topics/security/alert-cve-2010-4476-305811.html

The PCI-DSS standards are designed to help protect card-holder data. The specific section we’re interested in is section 4.1 of the v1.2 revision of the standards which are available for download here: https://www.pcisecuritystandards.org/security_standards/pci_dss_download_agreement.html

The standards layout that you should use strong cryptography and security protocols when transmitting card data over open, public networks (ie the Internet).

If you want to secure any data sent over HTTPS you need to make sure the protocols and ciphers used are secure. In practice, this means disabling SSLv2 and weak ciphers. This has to be done at the SSL endpoint – so if you’re using a load balancer, firewall or similar to terminate your SSL connections you’ll need to make the changes there.

We can offer advice and resell SSL terminating end-points. We also work with open-source SSl terminating solutions such as Pound ( http://www.apsis.ch/pound/ ).

How To Check

Use the SSLScan tool – http://sourceforge.net/projects/sslscan/

Use OpenSSL from the command line:

SSLv2

# openssl s_client -ssl2 -connect www.HOSTNAME.com:443

Weak ciphers

# openssl s_client -connect www.HOSTNAME.com:443 -cipher LOW:EXP

How to Fix

Apache 2.x:

SSLProtocol -ALL +SSLv3 +TLSv1

SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM

Pound:

Ciphers "SSLv3:TLSv1:-LOW:-aNULL:-ADH:-EXP:-eNULL"

IIS:

(Unfortunately you have to edit the registry…)

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128]
"Enabled"=dword:0000000

You may also be interested to know that active CF community member Pete Freitag has created a commercial tool to help you make these changes in IIS – http://foundeo.com/products/iis-weak-ssl-ciphers/

Of course not everyone’s environment is straight-forward and often you’ll hit issues or knock-on effects – so get the experts in… we’re waiting!