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
JRahm
Admin
AdminJRahmAdmin
Admin- JRahm@Balbus - thanks again for that, I've updated the string match.
@Aaron - that's great news! - JRahmNo, 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 :)
- JRahmThis should take care of it:
[string match "*22250738585072012*" [string map {. ""} [HTTP::request]]]
Updated the solution section to reflect this change. Thanks again! - JRahm@Balbus ... good catch. I'll work on an update.
