There's a very interesting vulnerability in Java kicking around. I wrote about
it here:
http://blog.fortify.com/blog/2011/02/08/Double-Trouble
In brief, you can send Java (and some versions of PHP) into an infinite loop if
you can provide some malicious input that will be parsed as a double-precision
floating point number.
This code used to look like the beginnings of some decent input validation:
Double.parseDouble(request.getParameter("d"));
Now it's the gateway to an easy DOS attack. (At least until you get a patch
from your Java vendor, many of whom haven't released patches yet. Oracle has
released a patch. Do you have it?)
Until a few days ago, all major releases of Tomcat made matters worse by
treating part of the Accept-Language header as a double. In other words, you
don't need to have any double-precision values in *your* code for your app to
be vulnerable.
The SC-L corner of the world puts a lot of emphasis on training and on looking
for known categories of vulnerabilities. That's all goodness. But this
example highlights the fact that we have to build systems and procedures that
can quickly adapt to address new risks.
Brian
_______________________________________________
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________
