What’s lurking in your Java library?
CERT (Computer Emergency Response Team) Secure Coding Team member David Svoboda took time out from riding the Security track at JavaOne to discuss Bash vulnerabilities, pernicious native layer hacks, and the downsides of publicising an exploit.
Voxxed: One of your JavaOne talks focused on the CERT Oracle Coding Standard for Java. Can you outline what this is for our readers?
David: Research shows that many vulnerabilities that are exploited in the wild result from simple coding errors rather than from insecure designs. As such, a deep understanding of the platform and language, such as Java, is required to write code that is free of vulnerabilities. The CERT Oracle Coding Standard for Java is a set of coding rules that helps programmers recognize and avoid vulnerabilities in their products.
Each rule provides simple instructions regarding what a programmer must and must not do. These instructions are accompanied by noncompliant code examples that violate the rule and consequently behave differently than expected. Each of these examples comes with one or more compliant solutions that eliminate the vulnerability. Finally, each rule has a simple mnemonic ID, which makes it quick and easy to find by googling.
Version 1.0 of The CERT Oracle Coding Standard for Java was published by Addison-Wesley in 2011. This book includes support for new features in Java SE 7. However, the standard continues to evolve, as does Java. We are currently updating the standard for Java SE 8 on our community wiki. We encourage the community to participate in the continuing evolution of the standard. Anyone is free to browse the standard and submit comments. Recognised experts are given the privilege of editing the standard, and community involvement has allowed us to produce a high-quality product.
What are the biggest security concerns you’re hearing about at the moment, and what would be your advice to readers?
At CERT, we’ve conducted dozens of Java source code audits using our Source Code Analysis Laboratory (SCALe), where we search for violations of the rules in the CERT Oracle Coding Standard for Java. And we always find some—I have yet to see code that complied with every rule in our standard.
Because the Java language has no memory corruption problems (such as buffer overflows), the most egregious vulnerabilities in Java tend to involve injection attacks such as SQL injections, cross-site scripting (XSS), and path injections. Chapter 2 of The CERT Oracle Secure Coding Standard for Java focuses on input validation and data sanitization as mechanisms for preventing injection attacks.
The best way to sanitize your input is to use the sanitization mechanisms that are provided by your platform. For example, if a user provides you with data that is going to be sent to a database, make sure it does not contain any internal SQL commands. JDBC’s PreparedStatement class is ideal for this purpose because it sanitizes untrusted input that is intended to be used in selection fields.
Many of the worst Java exploits have been caused by malicious applets. Java applets traditionally run with reduced privileges, and these restrictions are enforced by Java’s security manager. However, malicious applets have occasionally tricked the Java core library into disabling Java’s security manager, giving the applets full privileges to do anything that a C program could do on a remote user’s computer.
To prevent applets from being exploited, any code that might be used to manage an unprivileged applet must be aware of Java’s security restrictions. This includes all code in the Java core library. It also includes applets that run with special privileges but need not include unprivileged applets. The technical details of writing code that is aware of Java’s security architecture are covered in the Platform Security chapter of our Java coding standard.
Fortunately, these exploits do not affect the security of Java desktop or server applications.
Your other talk focused on the Anatomy of a Java Zero-Day Exploit. Do you think Java as a platform is becoming more insecure as hacks grow in sophistication (that is, penetration of the native layer)?
Improvements in Java security are constantly forcing attackers to become more sophisticated. Security is always an arms race; as security improves, the effort required to mount a successful attack also increases, which eliminates many bad actors. I think Java is a victim of its success: its widespread use and popularity make it a lucrative target. Only if it starts declining in popularity and hackers follow developers on to the “Next Big Thing” will Java become less of a target.
The scariest aspect of Java’s security is a consequence of Java’s huge core library, which provides a large attack surface that can conceal many vulnerabilities. As Java evolves, the library grows. And hackers know that a large codebase means many new vulnerabilities can be found and exploited. Each vulnerability is a golden opportunity for hackers to gain recognition among their peers or to sell their exploit for big bucks on the black market. An increasing number of governments are buying hackers’ exploits—or hiring the hackers.
What, in your opinion, should Oracle be doing to help users of legacy versions of the platform, ie. Java 6, secure their software?
The simplest answer would be to halt the development of new language and library features and focus on mitigating vulnerabilities. Oracle tried this approach for several months in 2013, but it was an unpopular move because users wanted Java 8 and had to wait while Oracle secured Java 7 (and earlier versions). Clearly, Oracle must balance security with the new features people want, and Oracle is still working on finding the right balance.
Another simple answer would be to make it harder to run Java applets, as the biggest Java exploits have targeted applets. Oracle has already made great strides in this direction by notifying users when they are about to run an applet and when their version of Java is out of date. Oracle could go further by separating distribution of the Java browser plugin from the rest of Java, as most people who run or even program Java don’t need applets.
The disclosure of the Bash vulnerability has generated a lot of press. How serious is it in your opinion?
The Bash vulnerability is definitely not as serious as Heartbleed was, but still is pretty serious. Even after an IT department had patched Heartbleed, its users (who are not necessarily IT professionals) still had to change passwords. The Bash vulnerability is unlikely to require the majority of users to change passwords.
The Bash vulnerability was a design error rather than a coding error. Bash parsed some environment variables as shell commands without anyone knowing. If Bash had been initially documented as having this feature, people would have been more careful about what environment variables they passed to Bash. For example, CGI scripts would not have used environment variables to send untrusted user parameters because many of them invoke Bash.
Nonetheless, this vulnerability is serious simply because Bash is at the heart of many UNIX systems, such as Max OS X, and is invoked in many surprising places—as part of CGI scripts and DHCP servers, for example. So a lot of work is required to simply discover whether your web server is affected, let alone patch it.
Do you think we should brace ourselves for a wave of Bash attacks down the line, and who is most vulnerable if so?
Every vulnerability, once published, invites a wave of attacks, and Shellshock is no exception. This vulnerability is like an earthquake—several aftershocks will likely be felt. That is, vulnerabilities will occur in systems that happen to rely on Bash. We already know about CGI and DHCP, but are there others? Any other such vulnerability, once published, will invite its own wave of attacks.
Can you tell us a little more about CERT’s projects? What problems is the organization looking to solve?
I am part of CERT’s Secure Coding Initiative, and our goal is to improve the level of security of code before it goes into production. This group was founded by Robert Seacord in 2003, and its goal is to reduce the number of vulnerability reports that the CERT Coordination Center receives. We try to improve the level of security by means of education and research. We teach Secure Coding in C and C++ to graduate students in Carnegie Mellon’s Information Networking Institute (INI) and to undergraduate students in CMU’s Institute for Software Research.
The SEI also offers a 4-day course for professional developers. We have a similar course for Java in the works—contact us if you are interested in either course. We publish secure coding standards on C and Java, and we also have nascent standards in C++ and Perl. We also offer a source-code auditing service to check for compliance with our standards through SCALe. Several research efforts in improving the state of software security are in progress. For example, we are adding checkers to the popular FindBugs static analysis tool; these checkers will test code for violations of The CERT Oracle Coding Standard for Java.
More information on our projects is available at http://www.cert.org/secure-coding/.