Mitigate Java Vulnerability with iRules

[JRahm]

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:

[JRahm]

@Balbus ... good catch. I'll work on an update.

[JRahm]

This should take care of it:[string match "*22250738585072012*" [string map {. ""} [HTTP::request]]]Updated the solution section to reflect this change. Thanks again!

[JRahm]

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]

@Balbus - thanks again for that, I've updated the string match.@Aaron - that's great news!