Hacker News Reader

Comment by mhansen | Hacker News Reader

Any public-facing Java server affected by this bug that accepts floating point numbers from the user as a string can be hung by this bug.

This is going to be a big problem.

View on HN

Excellent point. I'm going to have some tests to run when I get in to work this morning.

Yup. A comment on the original webpage reported that this value appears to hang/time-out Google Spreadsheet. I tested and it indeed was the case. So there are going to be lots of places one can fool around on the input side only to send the server thread into a loop. That's bad.

And yet...in 10+ years...it hasn't been a problem? Certainly the need to fix it but saying it is going to be a "big problem" is a bit theatrical.

Well, yeah. Nobody _accidentally_ hit upon this number, but now that it's a known way to commit a denial of service attack, people are going to take advantage of it.

Imagine your response, but about a kernel privilege escalation bug:

"And yet...in 10+ years...it hasn't been a problem? Certainly the need to fix it but saying it is going to be a "big problem" is a bit theatrical."

I tried to dig up a list of websites with a java-backend but my google-fu is not strong enough. I don't think that there are actually many big sites running on java.

There are tons of sites running on java. Possibly more than php.

Yup - http://wiki.java.net/bin/view/Projects/RealWorldJSFLinks

Anecdotally, a lot of those [\w+]tube porn sites probably run on a Java server considering the heavy lifting that goes on there.

Most of internet banking systems in my country run on Java. And most of them can be affected if you know where to put this number.

Yes, but fortunately, there is not much reason why anybody would use double when developing a banking system.

They don't have to use it directly.

GET / HTTP/1.0

Accept-Language: en;q=2.2250738585072012e-308

If you're running Tomcat and you call getLocale() on that servlet request, you're toast.

This is precisely why "q" is defined only to accept three digits after the decimal. It's actually not a floating point number, and anyone who parses it as such is just being lazy.

"q" is more properly represented natively as an integer between 0 and 1000.

apparently q is not properly parsed in JBoss which is based on apache tomcat scaring not?

Reply on news.ycombinator.com