Issue1705

Lately there has been quite of rumour in the Java community about the endless loop caused by a certain range of values.
Jython could be brought into such an endless loop simply by assigning the right value to a variable, such as
  value = a_bad_value

The Java hot spots are the following:
- BigDecimal.doubleValue()
- BigDecimal.floatValue()
- Double(String)
- Double.parseDouble(String)
- Double.valueOf(String)
- Float(String)
- Float.parseFloat(String)
- Float.valueOf(String)


The attached patch prevents these kind of attacks by replacing our usage of the hot spots above by a safer parsing strategy:

1) look for suspicious digits in the input string (heuristic, but quite fast)
2a) for suspicious values: use BigDecimal to safely parse them
2b) fix the real dangerous values by 'rounding' them to safe ones (outside the dangerous interval) 
For non-suspicious values, use the default fast Double parsing, as before

The performance penalty in the majority of cases is the detection of suspiciousness:

final protected static boolean isSuspicious(String s) {
  return digits(s).indexOf(SUSPICIOUS_DIGITS) >= 0;
}

final private static String digits(String s) {
  char[] ca = s.toCharArray();
  int len = ca.length;
  StringBuilder b = new StringBuilder(len);
  for (int i = 0; i < len; i++) {
    char c = ca[i];
    if (c >= '0' && c <= '9') {
      b.append(c);
    }
  }
  return b.toString();
}


Two questions:
 - does this sound reasonable ?
 - if yes, should we build that into 2.5.2 final ?

DoubleTroubleTestSuite.jar runs all the tests for the safer parsers.
It contains non jython specific java sources as well.

I'm not sure this is really worth the effort, since it's such a publicized  problem I expect a fix for the JVM will be released soon. One of the perks of running on top of the JVM is we can defer fixes like this to the JVM hackers

This blog post says it can be reproduced with a number of different numbers:
http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/

Sounds like it would be hard to detect them all as a workaround. The core integer parsing routine really needs a fix applied there

Oracle already fixed the issue: http://blogs.oracle.com/henrik/2011/02/double_trouble_-_fixing_a_java_security_issue.html

Maybe we'll need the workaround for older, unpatched versions of java.
If this should be the case, we can bury it out.
The workaround would detect all values in the actually known dangerous interval.

The first DoubleTroubleTestSuite.jar did not contain all sources.

Just had an email conversation with Charles Oliver Nutter. JRuby probably builds in this safety net.
Should we do as well, maybe for rc4?