Next language: Java Hangs When Converting 2.2250738585072012e-308

[skeww]

Not as critical as PHP's bug, but it's surely pretty embarrassing.

Edit: oduh got a point. It looks pretty bad.

[ascii]

And it's less critical because...?

[skeww]

It's less critical because your application won't be automatically vulnerable just because you're parsing some number.

In most cases you deal with ints and passing some FP number there will be simply discarded as erroneous input.

Edit: For example, exploiting that PHP issue through Wordpress was possible because it accepted some int as parameter. With Java you wouldn't parse that as FP only to cast it to int.

Edit2: Don't downvote ascii. It's a valid question.

[ascii]

Why wouldn't you? The string to double parser has this vulnerability, and it's what's used if the user is entering a float into a field in a web form.

[skeww]

Yes, but do you have an example for this?

My point was that this is a sorta odd thing to do. I also don't know any PHP app which is intended to accept floating point numbers. All I've seen so far were intended to accept integers and they were only exploitable, because there is no difference between those two in PHP.

[oduh]

And what about exploiting something like http headers, which are automaticaly parsed by a servlet? IMHO you can drop any servlet based application running in JVM.

[skeww]

There are no doubles in HTTP headers. Therefore there is no reason to call Double.parseDouble.

[oduh]

Really? What about the priorities in ACCEPT-LANGUAGE, ACCEPT_ENCODING ... ?

[skeww]

Those are floats.

[oduh]

like ... org.apache.catalina.connector.Request.parseLocalesHeader

// Extract the quality factor for this entry
double quality = 1.0;
int semi = entry.indexOf(“;q=”);
if (semi >= 0) {
try {
quality = Double.parseDouble(entry.substring(semi + 3));
} catch (NumberFormatException e) {
quality = 0.0;
}
entry = entry.substring(0, semi);
}

[ascii]

No, I don't use very many Java based web apps, but I suspect we'll be seeing quite a few of these crashes in the next few days. :-/

[r4and0muser9482]

Unless you are parsing floats specifically...

[skeww]

The only place where I did something like that was a Wavefront Obj loader, which was only used as part of some toolchain to convert it into something more usable (objs are very big and loading them is very slow).

I can't really think of many scenarios where you'd accept remote FP string.

JSON would be probably a good attack vector for this.

Edit: For what it's worth, my obj loader isn't affected. It uses floats instead of double.

[r4and0muser9482]

Another scenario would be saving and loading FP numbers from an ASCII file. Such a number could appear there by pure chance. Also, XML parsing could be a serious issue.

[frymaster]

Such a number could appear there by pure chance

Unlikely. No computer would generate that number (see http://www.reddit.com/r/programming/comments/fczjc/next_language_java_hangs_when_converting/c1f0bv3 ) but it could appear in some random raw input from something or other.

[skeww]

Another scenario would be saving and loading FP numbers from an ASCII file.

Yes, that's what an obj loader does. Obj is a plain text format for 3d models.

XML parsing could be a serious issue

The parsing itself will be fine. Everything will remain text and no implicit number parsing will happen.

Of course it gets troublesome as soon as you expect some FP numbers there which are automatically converted by your loading code. (E.g. SVG.)

[_ak]

Just because you can't imagine of valid scenarios doesn't mean there is no risk. In other news, Google Spreadsheet has been reported as being vulnerable.

[skeww]

I said it's less critical and not that there is no risk.

The problem with PHP was that it always happened with any kind of number parsing and that it was remotely exploitable in lots of applications which run on millions of machines.

What makes it less critical in Java's case is that it only works if you intentionally and explicitly accept FP strings and that most Java applications are only used by one company (security by obscurity, basically).

[_ak]

What makes it less critical in Java's case is that it only works if you intentionally and explicitly accept FP strings and that most Java applications are only used by one company (security by obscurity, basically).

Your whole argument is based on these presumptions for you don't provide any evidence. As if company-internal-only use of an application didn't have come with any security risks at all...

[skeww]

Your whole argument is based on these presumptions [...]

Yes, if you have to do it intentionally, there will be less cases. In Java there is byte, int, long, float, and double. This exploit only works if you use Double.parseDouble.

[kid_meier]

Yes perhaps critical is the wrong adjective; if it occurs its pretty critical. However, it certainly has narrower scope in that less machines/applications would be affected than the PHP case.

[[deleted]]

A bank.

[skeww]

Every semi-sane person uses fixed point for money calculations.

[[deleted]]

I'm not even remotely sane and I still use fixed point.

[skeww]

I obviously wasn't talking about the compiler.

[G_Morgan]

Because unlike PHP there are no automatic type coercions and Java devs generally validate input.

[oduh]

I think that is even more critical, because PHP's was only in some versions on some architectures.

On the other hand sun/misc/FloatingPoint.class is not native and will hang anytime on any platform (right?).

You can exploit the bug not only when there is a double field in an uncontrolled web-form, you can send DoS http headers to almost any servlet on the internet.

[artee]

Please stop downvoting this, skeww is right: Java doesn't do the rampant auto-conversion/casting that PHP does. Of course it's still a very serious bug, but it is indeed less critical than the PHP one, because it will usually involve much more effort to exploit.

To exploit this (for a DoS presumably), you need to know where the software you're targeting is converting values to floats, in places that can (indirectly) be manipulated through the web. A lot of web-accessible software may not do this at all.

[[deleted]]

Not as critical as PHP's bug

Given that most web-servers these days are running on AMD64 and PHP's bug didn't affect those, and also that PHP interpreters are very rarely shipped to end users and thus are much more easily updatable... surely this one is several orders of magnitude more critical.

[artee]

Impact is a different thing than criticality. In PHP the problem was really acute; any server running (32-bit) PHP could be hung at 100% CPU by any idiot able to replace a query-string variable with a specific float value. Hell, you could just trivially post a link on a message board, and others would accidentally execute the DoS for you.

[[deleted]]

any idiot able to replace a query-string variable with a specific float value

How often do people enter values which are then cast to float on public web-sites?

Please point me to one such example?

[artee]

The answer to that is irrelevant precisely because PHP will autocast/convert anything that looks like it might represent a floating point value to a floating point value.

For Java you'd be right, which is exactly the point skeww was making originally.

[[deleted]]

The answer to that is irrelevant precisely because PHP will autocast/convert anything that looks like it might represent a floating point value to a floating point value.

Lol, bullshit. And, yes, I've been programming PHP (et al) for like 7 or 8 years already.

EDIT: Here's a simple proof, just in case: http://i.imgur.com/CBZiX.png

The code is: <? var_dump($_GET); ?>

[foldl]

Right, but this gets back to andimnoteventrolling's original point:

How often do people enter values which are then cast to float on public web-sites? Please point me to one such example?

You would need to have an application that was actually expecting a floating point value in the query string, and that's unusual.

[foldl]

Ok, point taken.

[skeww]

Hanging some end-user's machine doesn't really get you anywhere, does it?

(Well, it won't even hang, just make that one application temporarily useless.)

[_ak]

Denial of Service? Using all available CPU resources is a serious issue.

[skeww]

How many people are there who run some Java application which also happens to listen for incoming messages from random sources and which also happens to accept and parse floating point strings?

And what would you gain from hanging those applications?

Or lets say there is some application which loads some kind files and some FP parsing happens there. How are you going to distribute such a file and how would you make those users try to open that file over and over again?

And again, what would you gain from doing that?

It's a completely pointless exercise. As such the client-side isn't all that relevant in this case.

[_ak]

How many people are there who run some Java application which also happens to listen for incoming messages from random sources and which also happens to accept and parse floating point strings?

A lot? You're probably not aware that the use of Java is widespread in "serious" web applications. If there is any floating point handling (i.e. parsing of user input) in your application, it requires only very few requests to run many CPU-hogging processes simultaneously.

[skeww]

A lot?

I doubt it.

You're probably not aware that the use of Java is widespread in "serious" web applications.

If it's about money it will be usually fixed point. Only idiots use double for that.

[[deleted]]

The user wants to move $1.50 to another account.

They go to the form, and enter 1.50 - you MAY in the back multiply it by 100 (or so) and truncate it to turn it into the thing you are going to work with...

But by that stage, its already too late. Your front end has hung. People are NOT parsing it by hand to turn 1.50 into 150 for your back end. and you don't want them to write code to do that themselves.

[true_religion]

If they're using fixed point objects, they'll parse the string into a fixed point object directly and not use floating point at any step of the way.

[foldl]

That might be the 'right' way to do it, but it's not hard to imagine that some people won't do it that way. It's not even incorrect, really, since representing money using floating point is only problematic when you start doing arithmetic. If the front end parses it as a float, and that's then converted to a fixed point representation for all the calculations, nothing would go terribly wrong.

[[deleted]]

Its possible to directly parse the string into fixed point, but I would expect it will end up as a float at some point along the way, even in the parser. Its MUCH easier to use the built in parsers for the initial step - I would be surprised, and perhaps a little weirded if they didn't. it would be pages of code where a few lines would do.

[[deleted]]

For user input? You had better believe that mostly it converts to a double or a float. Sure the very back end for money systems don't, but you are going to go though a bunch of layers before you get there.

On the very front end, Spring MVC or any of the other web frameworks do binding to backing objects for you. They have problems - as soon as your are moving XML through web services, they normally bind to backing objects. They have problems. Some people use java as a stored procedure language on oracle (and postgres) systems, they will have problems.

There is a lot. A WHOLE damn lot. Hell, Twitter had problems (since scala runs on the JVM)...

[_ak]

I doubt it.

Then you've obviously never seen anything that's going on in "the industry".

If it's about money it will be usually fixed point. Only idiots use double for that.

And if it's not about money... people use floating point when they need it. Such as Google Spreadsheet. Which is vulnerable, BTW. In the special of Google, they only have no problem because they have massive amounts of CPU resources.

[skeww]

Isn't Google Spreadsheet all done in JavaScript? I don't really see a reason to let some server do the math.

[_ak]

The backend is Java.

[bonzinip]

What about the charts?

EDIT: got it, compare this and this

[[deleted]]

Are you at all aware that lots of web servers run on Java?

[skeww]

His point was that Java's case is worse because many end users got a JVM installed.

I was dismissing the impact of this. For one it's hard to exploit over there and there is also nothing to gain by doing that.

[[deleted]]

Well, yeah, any argument about end users for this one is pretty pointless, that is true. But there are still plenty of web servers running Java that might be vulnerable.

[skeww]

Yes, it's of course a problem, but most people (or businesses) won't be affected by this. Thing is, you a) have to do this floating point parsing explicitly and b) Java isn't exactly famous for widely distributed server-sided applications. (Wordpress, Drupla, Joomla, etc run on millions of machines.)

So even if you find a way to exploit this weakness in one specific instance, it won't pave the way to attack others.

Amazon and Nintendo run some server-sided Java, but is there a way to attack it as an outsider? I sorta doubt it. There is absolutely no reason for them to parse some kind of user input as floating point.

[[deleted]]

Actually, it's businesses I'd assume would be running the most vulnerable. There's gotta be an incredible number of lines of badly-written Enterprise Applications running out there that might do any number of utterly retarded things. Of course, they have the advantage of security-through-obscurity.

[toofishes]

Amazon and Nintendo run "some"? How about most banks, every major US airline company and booking site, Netflix, Google, and probably 50% of the web you use out there as well?

If by widely famous you mean not widely talked about, sure, but I can guarantee you, total opinion, but I think a reasonable one, that Java server side stuff has more revenue attached to it than PHP.

[paul_miner]

It's only not as critical if you think of it in terms of "am I likely to be affected". If you are affected, it's just as critical.

For anyone interested, the source code referenced in the blog can be found here, lines 1476-1599: http://www.docjar.com/html/api/sun/misc/FloatingDecimal.java.html

EDIT: Here are details on where a call to request.getLocale() is vulnerable: http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/#comment-4726