Like this:

前两天网上爆出了一个Java浮点数运算的一个安全漏洞，利用该漏洞有可能会制造一次DDOS攻击，具体内容如下：

Information: http://www.oracle.com/technetwork/topics/security/alert-cve-2010-4476-305811.html

Path: http://www.oracle.com/technetwork/java/javase/fpupdater-tool-readme-305936.html

Demo:

Send a Java Program Into An Infinite Loop
Compile this program and run it; the program will hang (at least it does on a 32-bit system with the latest JRE/JDK):

class runhang {
public static void main(String[] args) {
System.out.println(“Test:”);
double d = Double.parseDouble(“2.2250738585072012e-308″);
System.out.println(“Value: ” + d);
}
}

—————————————————————————————————————-
Send the Java Compiler Into An Infinite Loop
Try to compile this program; the compiler will hang:
class compilehang {
public static void main(String[] args) {
double d = 2.2250738585072012e-308;
System.out.println(“Value: ” + d);
}
}

—————————————华丽的分割线——————————————————-

其实在有些团队，可能因为某些限制造成无法顺利打上官方的补丁，那有没有其他的低成本方案呢？这是我这几天一直在考虑的一个问题，结果Jim@OWASP.com昨天在twitter说，感兴趣的可以发Email给他一起讨论，于是给他发了个Email，结果迅速收到了Jim的feedback，在此对Jim在北美的半夜给我feedback表示无比的感谢！Jim在他的blog里讨论了这个问题，不幸的是Jim用的是blogspot.com发布blog，熟悉GFW的同学都知道，这个域名被GFW光荣的认证了，为了能让国内的同学们都了解这个solutions，所以翻墙过去把核心内容放到这里，感兴趣的同学请自取！

—————————————–再次华丽的分割———————————————————–

Here are a few approaches to tame the beast!

1) Generation 1 WAF rule (reject one number only)

This mod security rule only blocks a small portion of the DOSable range. The mod security team is working to improve this now (no disrespect meant at all!)

SecRule ARGS|REQUEST_HEADERS “@contains 2.2250738585072012e-308″ “phase:2,block,msg:’Java Floating Point DoS Attack’,tag:’CVE-2010-4476′”

I’ll update this post as soon as we get a deeper fix from our favorite FOSS WAFers.

Reference: http://mobile.twitter.com/modsecurity/status/35734652652093441

2) Generation 2 blacklist rejection J2EE filter (reject entire vulnerable range)

Team Adobe came up with this. It’s actually quite accurate in *rejecting input* in the DOSable JVM numeric range:

public static boolean containsMagicDoSNumber(String s) {
return s.replace(“.”, “”).contains(“2225073858507201″);
}

Reference: http://blogs.adobe.com/asset/2011/02/year-of-the-snail.html

3) Generation 3 IEEE data rounding J2EE validation POC (FTW from Brian Chess)

This following code is from Brian Chess at HP/Fortify. This is an impressive approach to this problem. I’m in the process of integrating this fix into ESAPI. This approach detects the evil range before trying to call parseDouble and returns the IEEE official value for any double in this most evil range ( 2.2250738585072014E-308 ).

private static BigDecimal bigBad;
private static BigDecimal smallBad;

static {
BigDecimal one = new BigDecimal(1);
BigDecimal two = new BigDecimal(2);
BigDecimal tiny = one.divide(two.pow(1022));
// 2^(-1022) ?? 2^(-1076)
bigBad = tiny.subtract(one.divide(two.pow(1076)));
//2^(-1022) ?? 2^(-1075)
smallBad = tiny.subtract(one.divide(two.pow(1075)));
}

if (arg == null) return false; // arg is null? return.
String noDot = arg.replace(“.”, “”);
if (!noDot.contains(“2225073858507201″)) return false;
// magic value not present? return.
BigDecimal bd;
try {
bd = new BigDecimal(arg);
} catch (NumberFormatException e) {
return false; // can’t parse? return.
}
if (bd.compareTo(smallBad) ！= 0) return false; // smaller than the smallest bad value or larger than the largest bad value? Return

// if you get here you know you’re looking at a bad value. The final
value for any double in this range is supposed to be
2.2250738585072014E-308

Reference: via email direct from Brian Chess and http://blog.fortify.com/blog/2011/02/08/Double-Trouble

尤其是第三个方案，太有技术含量了！NB！

附上Jim的blog原文地址，会翻墙的请看原文：http://manicode.blogspot.com/2011/02/taming-beast-java-double-dos.html