David Baxter PhD
Late Founder
Security Experts Recommend Long, Hard Look at Disabling Java Browser Plug-In
by Michael Mimoso
October 4, 2012
Is the Java browser plug-in the IT equivalent of the human appendix? Would you miss it if it were gone? Probably not, experts say, especially now that attackers are beating the Java sandbox with a rash of zero-day exploits.
“It's simply safer to have the Java plug-in disabled in the browser knowing that there is a security bug in it that could be potentially exploited to gain access to the system,” said Adam Gowdiak, CEO and founder of Security Explorations, a security consultancy in Poland. Gowdiak and his team discovered the latest zero-day in Java, this one in versions 5, 6 and 7 that would allow a complete sandbox escape and give an attacker full remote control of a compromised computer.
Gowdiak’s exploit was the second assault on Java in the last 45 days. A zero-day in Java 7 was discovered in late August and the exploit included the PoisonIvy remote access Trojan. With more than 1 billion Java installations on computers worldwide, there may not be a bigger, more vulnerable target than Java on browsers. Yet, relatively few websites require Java to view content. This is especially true for consumers, who often are less security savvy than their business counterparts. Business users are likely to feel more of an impact should Java be disabled, or abandoned altogether, because some mission-critical collaboration applications such as WebEx or GoToMeeting are built on Java.
“Java code runs on many devices, but is especially prevalent in internet browsers, such as Internet Explorer. This gives attackers targeting Java vulnerabilities direct access to their victims,” said Chris Valasek, senior security researcher with application security company Coverity. Valasek points out that most Java bugs aren’t similar to the memory corruption problems plaguing Windows and IE, for example. He said they are design logic or architectural issues that permit an attacker to run Java code on the machine as if it were a local command, and not from the Web.
“This permits actions not intended, such as starting other processes and writing to the disk,” Valasek said. “This ease-of-exploitation factor plays a major part in the Java vulnerabilities being exploited by attackers.”
Experts say disabling Java makes sense from a security standpoint; many don’t have the plug-in installed or have a dedicated browser installed just for when Java functionality is required, such as WebEx meetings.
“Most of the things that only Java could do a few years ago can now also be done with HTML5 and Flash Player,” said Atif Mushtaq, senior staff scientist at FireEye. “A vast majority of desktop users don't really need Java running inside their browsers.”
Marcus Ranum, a security pioneer, remembers the early days of Java and the rush to code business logic on top of Java despite known implementation flaws in the engine, he said. “When it first came out, it didn’t take long for guys like Ed Felten and Gary McGraw to start finding holes in Java,” Ranum said. “People should have said ‘wait a minute’ then.”
Companies coding mistakes on top of Java aren’t facing the same threats zero-days pose, but simple errors such as forgetting to require authentication or coding in a SQL injection bug, can open equally dangerous holes.
“What’s frustrating about Java is that it’s playing itself out exactly the way security experts predicted it would,” Ranum said. “I think organizations need to take a look at how much Java they’ve got. When was the last time you ran into a Java website? If you don’t have a Java engine installed, chances are you don’t miss it. The hard thing with Java is I know of a lot of enterprises with substantial investments in code on the backend all Java. Maybe they’ll think harder next time.”
Part of the frustration with Java security issues has to do with Oracle, which owns the Java code base since acquiring Sun in April 2009. Experts have been critical of Oracle’s patch cycles and the speed with which updates are made available, especially out of band.
“In my opinion if Oracle is really serious about the security of billions of end users they need to be more vigilant when it comes to fixing their software. You need a different mindset when dealing with a consumer product being used by the masses as compared to an enterprise software product,” said FireEye’s Mushtaq. “A patch cycle of a couple of months for enterprise software might be acceptable but, when it comes to Java running inside billions of browsers, the patching cycle should happen within weeks if not days. Needless to say, even if there is a delay for the final patch, at the least, mitigation techniques should be published immediately.”
Tod Beardsley, engineering manager for Rapid7 and Metasploit hopes the latest run of zero-days is a wake-up call for Oracle.
“If Oracle is going to take ownership of the platform, then take ownership and get on the stick,” Beardsley said. “The same thing happened to Microsoft with things like ActiveX. Now it’s Oracle’s turn. I’m sure they’ll get better too.”
With exploit modules written almost immediately for Metasploit, the time to exploits in the wild is very short for users.
“It is somewhat simpler to write a Java exploit,” said Beardsley. “You tend to not be dealing with complicated things like buffer overflows. You deal with things like escaping sandboxing, which is technically easier to approach.”
In the meantime, experts say shut down those Java plug-ins.
“Disabling Java in the Web browser seems to be a good idea for now,” Coverity’s Valasek said. “It seems right now that having the Java plug-in is a liability and its use should be limited if not completely avoided.”
by Michael Mimoso
October 4, 2012
Is the Java browser plug-in the IT equivalent of the human appendix? Would you miss it if it were gone? Probably not, experts say, especially now that attackers are beating the Java sandbox with a rash of zero-day exploits.
“It's simply safer to have the Java plug-in disabled in the browser knowing that there is a security bug in it that could be potentially exploited to gain access to the system,” said Adam Gowdiak, CEO and founder of Security Explorations, a security consultancy in Poland. Gowdiak and his team discovered the latest zero-day in Java, this one in versions 5, 6 and 7 that would allow a complete sandbox escape and give an attacker full remote control of a compromised computer.
Gowdiak’s exploit was the second assault on Java in the last 45 days. A zero-day in Java 7 was discovered in late August and the exploit included the PoisonIvy remote access Trojan. With more than 1 billion Java installations on computers worldwide, there may not be a bigger, more vulnerable target than Java on browsers. Yet, relatively few websites require Java to view content. This is especially true for consumers, who often are less security savvy than their business counterparts. Business users are likely to feel more of an impact should Java be disabled, or abandoned altogether, because some mission-critical collaboration applications such as WebEx or GoToMeeting are built on Java.
“Java code runs on many devices, but is especially prevalent in internet browsers, such as Internet Explorer. This gives attackers targeting Java vulnerabilities direct access to their victims,” said Chris Valasek, senior security researcher with application security company Coverity. Valasek points out that most Java bugs aren’t similar to the memory corruption problems plaguing Windows and IE, for example. He said they are design logic or architectural issues that permit an attacker to run Java code on the machine as if it were a local command, and not from the Web.
“This permits actions not intended, such as starting other processes and writing to the disk,” Valasek said. “This ease-of-exploitation factor plays a major part in the Java vulnerabilities being exploited by attackers.”
Experts say disabling Java makes sense from a security standpoint; many don’t have the plug-in installed or have a dedicated browser installed just for when Java functionality is required, such as WebEx meetings.
“Most of the things that only Java could do a few years ago can now also be done with HTML5 and Flash Player,” said Atif Mushtaq, senior staff scientist at FireEye. “A vast majority of desktop users don't really need Java running inside their browsers.”
Marcus Ranum, a security pioneer, remembers the early days of Java and the rush to code business logic on top of Java despite known implementation flaws in the engine, he said. “When it first came out, it didn’t take long for guys like Ed Felten and Gary McGraw to start finding holes in Java,” Ranum said. “People should have said ‘wait a minute’ then.”
Companies coding mistakes on top of Java aren’t facing the same threats zero-days pose, but simple errors such as forgetting to require authentication or coding in a SQL injection bug, can open equally dangerous holes.
“What’s frustrating about Java is that it’s playing itself out exactly the way security experts predicted it would,” Ranum said. “I think organizations need to take a look at how much Java they’ve got. When was the last time you ran into a Java website? If you don’t have a Java engine installed, chances are you don’t miss it. The hard thing with Java is I know of a lot of enterprises with substantial investments in code on the backend all Java. Maybe they’ll think harder next time.”
Part of the frustration with Java security issues has to do with Oracle, which owns the Java code base since acquiring Sun in April 2009. Experts have been critical of Oracle’s patch cycles and the speed with which updates are made available, especially out of band.
“In my opinion if Oracle is really serious about the security of billions of end users they need to be more vigilant when it comes to fixing their software. You need a different mindset when dealing with a consumer product being used by the masses as compared to an enterprise software product,” said FireEye’s Mushtaq. “A patch cycle of a couple of months for enterprise software might be acceptable but, when it comes to Java running inside billions of browsers, the patching cycle should happen within weeks if not days. Needless to say, even if there is a delay for the final patch, at the least, mitigation techniques should be published immediately.”
Tod Beardsley, engineering manager for Rapid7 and Metasploit hopes the latest run of zero-days is a wake-up call for Oracle.
“If Oracle is going to take ownership of the platform, then take ownership and get on the stick,” Beardsley said. “The same thing happened to Microsoft with things like ActiveX. Now it’s Oracle’s turn. I’m sure they’ll get better too.”
With exploit modules written almost immediately for Metasploit, the time to exploits in the wild is very short for users.
“It is somewhat simpler to write a Java exploit,” said Beardsley. “You tend to not be dealing with complicated things like buffer overflows. You deal with things like escaping sandboxing, which is technically easier to approach.”
In the meantime, experts say shut down those Java plug-ins.
“Disabling Java in the Web browser seems to be a good idea for now,” Coverity’s Valasek said. “It seems right now that having the Java plug-in is a liability and its use should be limited if not completely avoided.”