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

Save to:
Instapaper Pocket Readability

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. Note that this isn't to single out Java; other managed code environments have had similar vulnerabilities reported as well.

Today CERT posted an analysis of the current Java vulnerabilities, written by our own ISO C++ committee member David Svoboda:

Anatomy of Java Exploits

by David Svoboda

Java was exploited recently and last August. The August exploit was patched by Oracle on August 30; this most recent exploit now also has a patch available. Strictly speaking, the vulnerabilities that permitted both exploits are independent; the current exploit attacked code that was unused by the August exploit. Nevertheless, these vulnerabilities were quite similar. This blog post examines the vulnerabilities that permitted Java to be exploited in each case, using the proof-of-concept code exploits that have been published for them in January 2013 and August 2012.

The article demonstrates and comments on how security issues are common to all modern languages. From the conclusion:

While many previous Java vulnerabilities were actually vulnerabilities in the C code of a particular Java implementation, these exploits ran with pure Java -- no underlying C/C++ vulnerability was involved.

This doesn't mean Java is a horrible language any more than vulnerabilities in C and C++ make those horrible languages. Rather, it emphasizes that security is hard in any language or environment, and pretending otherwise is never helpful. For example, CERT publishes secure coding guidlines for various languages (the Java book coauthored by the author of the blog post above, David Svoboda):

And as Svoboda's CERT blog post today noted, many of today's popular attacks aren't language-specific, and:

... injection attacks, such as SQL injection, cross-site scripting (XSS), and command injection, occur in all languages that permit string manipulation.

Just like it isn't enough to think that using C++, which advertises an emphasis on performance, by itself means your code will be fast, it isn't enough to think that using a language that advertises an emphasis on safety means your code will be secure. As Robert Seacord, author or coauthor of both books above, said in email yesterday:

"The fact is that you need to understand the problems in whatever language you are using and diligently apply secure coding practices and principles if you want to have any hope of developing secure systems."

That's a lesson we can all benefit from, no matter which modern mainstream language we use.

Add a Comment

You must sign in or register to add a comment.

Comments (3)

5 0

Eric Niebler said on Jan 15, 2013 05:50 PM:

This is, after all, the promise of Java: write once, exploit anywhere. tongue laugh
0 0

Michael said on Jan 23, 2013 10:05 AM:

"injection attacks, such as SQL injection, cross-site scripting (XSS), and command injection, occur in all languages that permit string manipulation"

This is true, but if we look at root causes we can conclude that it's about library, not core language: "injection attacks occur in all languages with standard library that does not provide parametrized queries, parametrized command and parametrized web templates that are as easy to use as string manipulation"

Can we have parametrized command in C++17? I want to stop using system().
0 0

Seth Williams said on Apr 5, 2013 05:55 AM:

It is true. You cannot blame the language for vulnerabilities as it is almost impossible to account for everything. The developers must try to implement and follow Secure Coding Standards in order to avoid such issues.