Commission faults Oracle’s Java SE update process with making consumers’ computers insecure.
Oracle received a public slap on the wrist from the US Federal Trade Commission over Java SE, the desktop runtime for Java. The FTC announced today that it had reached a settlement with Oracle Corporation over a complaint not about the security of Java itself, but about Oracle’s patching process—and how it unintentionally left consumers to believe that the patches themselves were enough.
Java has been a source of perpetual security sorrow due to the number of exploitable flaws that have been discovered in various versions of Java SE. That’s partially due to its huge installed base—over 850 million PCs are estimated to have Java SE installed on them, and it isn’t always the most recent version. Older versions of Java create a major security risk—even when newer versions have been installed.
And there lies the rub of the FTC’s complaint. Since at least 2010, Java SE updates have not done a thorough job of cleaning up the insecure versions—and, the FTC contends, Oracle failed to advise consumers doing the updating that the job was only half done.
“Oracle failed to disclose, or failed to disclose adequately, that, in numerous instances, updating Java SE would not delete or replace all older iterations of Java SE on a consumer’s computer, and as a result, a consumer’s computer could still have iterations of Java SE installed that are vulnerable to security risks,” the FTC stated in its complaint. “This fact would be material to consumers’ decisions whether to take further action after ‘updating’ Java SE to protect their computers.”
Because malware writers and cybercriminals closely monitor Oracle’s Java security updates, they are able to relatively quickly develop exploits of recently deprecated versions of Java SE. Late in 2010, Oracle was aware that “at least 44 Java SE vulnerabilities were publicly available,” the FTC noted in its complaint. “For example, attackers have used known exploit kits targeting Java SE vulnerabilities to install key loggers that would capture consumers’ usernames and passwords, which could be used to log into a consumer’s PayPal, bank, and credit card accounts.”
But Java SE updates, when they were issued, only removed the latest version of Java prior to the update. Anything released before Java SE 6.10 was left completely alone by the update process because these versions were installed in different directories on PCs and not in the default location used by the new updater. Oracle explained that customers might have multiple old versions left on their computers—but the company did so on a “separate FAQ page of Oracle’s website,” the FTC complaint noted, not on the Java update page or in the updater software itself. And Oracle failed to link to the FAQ from the update page as well.
Oracle even knew that this was a problem, noting in internal documents that vulnerable versions of Java were still being targeted successfully by malware after updates were pushed out. Oracle executives admitted internally that the “Java update mechanism is not aggressive enough or is simply not working.” But the company never did anything about informing customers about this, and continued to follow the same update process for Java SE 7 and 8—continuing to leave many customers vulnerable to malware.
This failure to disclose was cited by the FTC as a “deceptive act or process” in violation of the Federal Trade Commission Act. In its proposed settlement with the FTC over the issue, Oracle has posted a Java Uninstall tool on its website, and has agreed to notify consumers directly of the security threat posed by old versions of Java.
Oracle’s failure to fully inform consumers will likely not come as a surprise to many in the security field. Oracle has taken a famously combative stance on security with even its enterprise customers, and especially with the security research community. In August, Oracle chief security officer Mary Ann Davidson wrote a (quickly removed) blog post excoriating customers who hunt for bugs in Oracle’s code, calling it “reverse engineering” and a violation of Oracle’s software license. “If we determine as part of our analysis that scan results could only have come from reverse engineering (in at least one case, because the report said, cleverly enough, “static analysis of Oracle XXXXXX”),” wrote Davidson, “we send a letter to the sinning customer, and a different letter to the sinning consultant-acting-on-customer’s behalf—reminding them of the terms of the Oracle license agreement that preclude reverse engineering, So Please Stop It Already.”
Oracle’s executive vice president and chief corporate architect Edward Screven told Ars at the time that Davidson’s post was removed because “it does not reflect our beliefs or our relationship with our customers.”
Source:https://arstechnica.com/
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
