Java vulnerabilities

With the help of friends Robert Seacord and David Svoboda of CERT in particular, I posted a note and link to their CERT post today because people have been misunderstanding the recent Java vulnerabilities, thinking they’re somehow really C or C++ vulnerabilities because Java is implemented in C and C++.

From the post:

Are the Java vulnerabilities actually C and C++ vulnerabilities?

by Herb Sutter

 

You’ve probably seen the headlines:

[US-CERT] Java in Web Browser: Disable Now!

We’ve been telling people to disable Java for years. … We have confirmed that VU#625617 can be used to reliably execute code on Windows, OS X, and Linux platforms. And the exploit code for the vulnerability is publicly available and already incorporated into exploit kits. This should be enough motivation for you to turn Java off.

Firefox and Apple have blocked Java while U.S. Homeland Security recommends everyone disable it, because of vulnerabilities
Homeland Security still advises disabling Java, even after update

Some people have asked whether last week’s and similar recent Java vulnerabilities are actually C or C++ vulnerabilities – because, like virtually all modern systems software, Java is implemented in C and C++.

The answer is no, these particular exploits are pure Java. Some other exploits have indeed used vulnerabilities in Java’s native C code implementation, but the major vulnerabilities in the news lately are in Java itself, and they enable portable exploits on any operating system with a single program. …

Some other C++ experts who have better sense than I do won’t add the following bit publicly, but I can’t help myself: Insert “write once, pwn everywhere” joke here…

6 thoughts on “Java vulnerabilities

  1. One could surely say that now it is:
    “No time for Java” :P
    http://www.youtube.com/watch?v=xF0-LGoXtaw
    BTW Herb IDK if you read comments, but you posted a link recently(feedback for new lambda syntax and nobody responded to isocpp.org comments. If you wanted ppl to post only on the mailing list you should have said to, this way it looks a bit rude. :D

  2. Well, Java is not just a language, like C++, it’s framework, which is pretty complicated. And its the particular implementation of that framework which has these bugs. So, at the first place, making such comparison is not fair.

    Another point is that the most of such framework bugs are related to sandbox, which is used to run applets and which is not used for any other purposes (of course some people can, but that’s good way to shoot your own leg). It means that unless your app is an applet (about 99.999% of all java apps) you are not affected.

    Thanks for joke anyway.

  3. Thx for the post, Herb. Although Java is a language and a platform, the important bits for me are that the solution is not in patching the underlying OS (libraries), rather in patching either the JVM or the Java libraries, or both.

  4. You forgot to mention that those vulnerabilities only affect Oracle’s Java implementation, and to a certain extent the OpenJDK. There are many other Java runtimes out there from several vendors.

    Unfortunately the normal public tends to mix language with implementation, so they think Oracle’s Java means any Java implementation.

    As for C and C++ vulnerabilities, those are usually on the languages themselves, because even expert programmers are prone to shot themselves on the foot when doing pointer and array manipulation, or dealing with null terminated strings.

    C++ makes the situation better than C, but even in 2013 not everyone is allowed to use the standard C++ library on their projects.

  5. stanislavk – surely the point is that the bug arose from Java programmers programming in Java, not C++ programmers programming in C++. It might have been the latter, since Java is built on top of C++, but it wasn’t. I think that point is worth making, and I don’t see why it’s unfair. It would be unfair to blame this Java bug on C++.

Comments are closed.