DWR

Thanks for notifying us of this but I am not seeing how this is a DWR bug. I see how it can affect web applications using DWR and I see that by wrapping Double we could get around it but ....

What are your suggestions?

Oracle will fix. there'll be multiple exploitable vms still out there. multiple apps. overall its a pretty yucky situation. frameworks involved in parsing user inputs to double should maybe go a bit out of their way to prevent issues.

// puts java into an infinite cpu loop. scary.
if("2.2250738585072012e-308".equalsIgnoreCase(s)) { return Double.MIN_VALUE; }
return Double.parseDouble(s);

Right. I am not a huge fan of introducing this type of weird logic into the framework. I think this seems to be quite an edge case (certain JDK, certain value - which of course is now a known exploit thanks to the comment on the link you posted). Seems like you could just as easily protect against it at the application level (via a filter, etc.).

Yes, our code does make use of Double.parseDouble and the similar Double.valueOf. Unfortunately, the fix is not so simple though, as (according to the article you supplied):

1) a range of numbers trigger the bug
It is not only hanging for 2.2250738585072012e-308.
It is hanging for any number between
2^(-1022) – 2^(-1075) and
2^(-1022) – 2^(-1076).
For example, 2.22507385850720117e-308

2) modified forms of the same number triggers the bug
0.00022250738585072012e-304 (decimal point placement)
00000000002.2250738585072012e-308 (leading zeros)
2.225073858507201200000e-308 (trailing zeros)
2.2250738585072012e-00308 (leading zeros in the exponent)
2.2250738585072012997800001e-308 (superfluous digits beyond digit 17)

So to catch the offending numbers it seems we would almost have to write our own floating point parser
Still, if there is a straight-forward and performant way to catch these we could consider adding it to LocalUtil.simpleConvert() where our double conversion takes place, with a note to remove it once we expect the world to have upgraded to newer JREs.