Mitigate Java Vulnerability with iRules

I got a request yesterday morning to asking if there was a way to drop HTTP requests if a certain number was referenced in the Accept-Language header. The user referenced this post on Exploring Binary. The number, 2.2250738585072012e-308, causes the Java runtime and compiler to go into an infinite loop when converting it to double-precision binary floating-point. Not good. Twitter is ablaze on the issue, and there is a good discussion thread on Hacker News as well. So how do you stop it? At first, this appeared to be a no-brainer, just copy that string and drop if found in that header, right? Well, there’s a catch. A few actually. This number can be represented in many ways:

Decimal point placement => 0.00022250738585072012e-304
Leading Zeroes => 00000000002.2250738585072012e-308
Trailing Zeroes => 2.225073858507201200000e-308
Leading Zeroes in the Exponent => 2.2250738585072012e-00308
Superfluous Digits past digit 17 => 2.2250738585072012997800001e-308

String match seemed the perfect fit for this as I need a few wildcards to sort this out. I started in the Tcl shell just to make sure all the use cases matched:

Published Feb 03, 2011

Version 1.0

Was this article helpful?

4 Comments

JRahm
Admin
Feb 03, 2011
@Balbus ... good catch. I'll work on an update.
JRahm
Admin
Feb 04, 2011
This should take care of it:

[string match "*22250738585072012*" [string map {. ""} [HTTP::request]]]

Updated the solution section to reflect this change. Thanks again!
JRahm
Admin
Feb 04, 2011
No, this iRule only looks at the headers. However, you could look for a POST and do an HTTP::collect, then perform the match on the payload in the HTTP_REQUEST_DATA event. Depending on how large the POST is, that could slow things down considerable. Not as considerable as crashing java though, I suppose :)
JRahm
Admin
Feb 09, 2011
@Balbus - thanks again for that, I've updated the string match.

@Aaron - that's great news!