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
  • @Balbus - thanks again for that, I've updated the string match.

     

     

    @Aaron - that's great news!
  • 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 :)
  • This should take care of it:

     

     

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

     

     

    Updated the solution section to reflect this change. Thanks again!