By Stephen Cobb, Sr. Security Researcher, ESET
In its ongoing efforts to improve the security of the nation’s computers, the federal government recently requested the assistance of ESET and a handful of other companies. In this article I explain how this came about, how ESET reacted and the subject of the government’s concern. Here are some hints: It involves Java (the programming language, not the beverage) and Oracle (the software company, not the source of prophecy). And for those in a hurry, you can go straight to this page on We Live Security, where ESET has delivered the requested assistance, as a sort of security bulletin.
For many years, criminals armed with malicious code have exploited security weaknesses in something called the Java Platform, Standard Edition (“Java SE”). This is code that enables people to run a wide range of applications on their computers, from online games to mortgage calculators and image viewers. Java SE is part of an entire programming environment that is known for its ability to run on a wide range of computing devices, from corporate desktops to routers, smartphones, ATMs, TVs and even cars. In 2010, Java was acquired by Oracle, known for its database technology. This meant that Oracle became responsible for fixing any security vulnerabilities discovered in the Java SE code installed on consumer computers.
Unfortunately, the approach that Oracle took to patching Java SE code was problematic, both practically and legally. Practically speaking, for a number of years, whenever you proceeded to install a Java SE update, the previous version was left on the computer, unpatched and insecure almost by definition (you were doing the update because holes had been discovered in a previous version). The “exploit kits” that criminals use to compromise computers for data theft and other cybercrimes detect the presence of vulnerable versions of Java SE; then they used them to deploy malicious code, even if the system also had the latest and “most secure yet” version of Java installed.
The legal problem goes like this: During the Java SE update process a series of screens stated that “Java provides safe and secure access to the world of amazing Java content.” The screen told consumers that Java SE updates would provide “the latest…security improvements.” However, Oracle did not adequately disclose that: “…in numerous instances, updating Java SE would not delete or replace all older iterations of Java SE on a consumer’s computer. As a result, a consumer’s computer could still have iterations of Java SE installed that are vulnerable to security risks.” That language comes from the complaint that was filed against Oracle by the U.S. Federal Trade Commission (FTC).
What does the FTC have to do with software security? The short answer is: A lot. The agency has successfully argued, through cases dating back to the turn of the century, that making unsupported claims about the security of your software and/or systems is a deceptive business practice. The same can be said of failure to disclose information that would help consumers protect their systems. You can read more about the role of the FTC in policing data privacy and security in the U.S. in this ESET white paper.
To cut a long story short, Oracle entered into a Consent Order with the FTC last month, a 20-year settlement in which the company agreed to help consumers remove older versions of Java SE still sitting on their computers, while also educating the public about the risks that these versions pose. For example, the order specified the posting of the link that you now see at the top of the java.com home page: “IMPORTANT INFORMATION REGARDING THE SECURITY OF JAVA SE.” That link, mandated by Section III.A of the order, leads to a page which provides information about the Java SE security issue and the uninstall tool that Oracle has provided to the public. The contents of that page were agreed upon between Oracle and the FTC and are referred to as Attachment A.
So where does ESET come into the picture? Well, in section III.B of the order, the FTC requires Oracle to contact ESET North America and seven other companies, “to request that these entities publish this notice [Attachment A] in their security bulletins.” In other words, the FTC asked Oracle to ask ESET to publish a notice to consumers to help them make their systems more secure. And that is what we did, by means of this article on our blog We Live Security.
Of course, we did a little research before we went ahead with this. We asked the FTC how it came up with that list of company names. They were not inclined to say, but it seems logical to assume the FTC considers them the most proactive companies in the consumer cybersecurity space. They were inclined to clarify that ESET was not legally required to post this article. We decided that the message was important, and that the consumer protection mission of the FTC is a commendable one, so we decided to post it. (We asked if a page on We Live Security met the criteria for “publish this notice in their security bulletins” and the FTC said it did.)
We also talked to Oracle to make sure the company is prepared to support the Java SE Uninstall Tool. After all, ESET does not want to be the point of contact for support calls from people struggling with Java SE issues just because we pointed out the problem (to an audience of affected persons that could number in the millions). Oracle says it is indeed ready to support users and our article highlights the resources available for this.
In addition, we had an internal discussion about the use of Java in an ESET product: ERA, the ESET Remote Administrator. This application enables organizations to manage ESET security software across thousands of machines and multiple platforms (Windows, Mac OS X, Linux, Android and iOS). To be clear, the end user machines that are being managed through ERA don’t need to run Java. The users of ERA, the security administrators doing the managing, do need Java on their systems to run the ERA console. These folks will likely be using the latest version of Java SE already. The exception might be: “If the latest version has not been tested to ensure compatibility with other applications.”
This exception is one of the challenges faced by Oracle when it acquired Java: Some applications written in Java could break after a Java upgrade. That’s why the Oracle web page about uninstalling Java displays this warning: You should only follow these instructions if you personally own the system in question. For Company-owned systems please contact your company for instructions.
For consumers the message is clear: Read the security bulletin on We Live Security and act accordingly. We have provided some helpful notes below the official statement from Oracle, and we’re always happy to help out the FTC. Just remember who you’re gonna call if the Java Uninstall process gives you any problems. That would be Oracle.