4

There is a new Java released a couple days ago to resolve a hole that was recently discovered.
(Oracle, US-CERT, NVD/NIST)

In my initial reading about this update 11, I saw clearly where it by default partially disabled the run-without-asking functionality, but didn't see where it was actually fixing the underlying problem. So, is the following info correct?

  • Is the vulnerability on the Java sandbox found in both 7u10 and 7u11?
  • Am I right that this is almost exclusively a problem with the Java plug-in (web browsing with Java enabled), but does have consequences in some generally unknown applications that make use of the sandbox.
  • Is it true that the only way to sidestep the problem is to prevent code you don't trust from running. (either disable Java, or adjust to always ask before running applets)
  • Is it true that the only relevant difference between 7u10 and 7u11 is that instead of (by default) running applets without asking, Java 7u11 will ask the user before running unsigned applets, while remaining to run signed apps without asking. Which would mean that signed apps can still be used to exploit the vulnerability?
700 Software
  • 13,807
  • 3
  • 52
  • 82
  • 4
    Which vulnerability are you talking about? If Oracle says the fix resolves it then, absent evidence to the contrary, I think it's reasonable to presume it does. A CVE ID or link to a specific article regarding the specific vulnerability you're asking about would be useful. – Iszi Jan 15 '13 at 20:49
  • This question seems far to localized to be any assistance a week from now. Furthermore 20 hours ago the answer to this question was different, the problem that was fix is incomplete and even with Update 11 people are vulerable to an exploit. – Ramhound Jan 16 '13 at 17:09
  • @Ramhound, *"...fix is incomplete and even with Update 11 people are vulnerable..."* Please point us to how you discovered this and/or what your reasoning is, and post that as an answer. – 700 Software Jan 16 '13 at 20:13
  • @GeorgeBailey Please be aware this is a Question & Answer board, not a discussion forum. It is generally bad form to edit a question in such a way that it invalidates answers, or to roll answer details up into the question. If your intent is to ask a different question, based on what you've learned from the answers here, then it should be started as a separate thread. – Iszi Jan 16 '13 at 21:43
  • 1
    @Ramhound While the *usefulness* of this question is relatively time-localized, its explicit specification of versions (7u10, 7u11) means that the question *itself* is not. Lessons can still be learned from past vulnerabilities and their fixes, so I would not be inclined to suggest closing it. – Iszi Jan 16 '13 at 21:45
  • @GeorgeBailey - There are already reports that the exploit that was fixed within Update 11 might have been incomplete. US CERT still suggests you disable Java within your browser even with Update 11 installed. – Ramhound Jan 17 '13 at 11:57
  • 1
    @Ramhound, (If I may be so bold) What reports? I have so far not seen an article about Update 11 which is describing a remaining known vulnerability. – 700 Software Jan 17 '13 at 18:52
  • @Iszi, **"not a discussion forum**" I will try to keep it that way. **"bad form to edit a question in such a way that it invalidates answers"** I did not mean to. **"or to roll answer details up into the question"** I did not mean to. **"If your intent is to ask a different question"**, it's not. Thanks for watching out. I will post another edit, so maybe it will turn out better. – 700 Software Jan 17 '13 at 19:07
  • @GeorgeBailey - https://krebsonsecurity.com/2013/01/new-java-exploit-fetches-5000-per-buyer/ – Ramhound Jan 17 '13 at 19:11
  • @Ramhound, I am using your comments to assist in my answer, but feel free to make your own answer. You deserve the credit. – 700 Software Jan 17 '13 at 19:24
  • @GeorgeBailey - As of Friday( Jan 18 2012 ) Java 7 Update 11 is vulnerable to a very similar exploit that it was suppose to fix. http://seclists.org/fulldisclosure/2013/Jan/142 – Ramhound Jan 19 '13 at 03:28

2 Answers2

6

The linked CNET article refers to CVE-2013-0422 "Oracle Java 7 Security Manager Bypass Vulnerability" (Oracle, US-CERT, NVD/NIST). From the Oracle link: "Affected product releases and versions: JDK and JRE 7 Update 10 and earlier".

  • "The vulnerability on the Java sandbox exists in both 7u10 and 7u11" is incorrect. 7u10 is vulnerable. 7u11 is not. The update notes suggest that the bug was fixed by code changes, not by simply changing the default security level as you seem to imply in your final bullet point.

  • The Java browser plugins are very problematic because they allow drive-by type attacks against vulnerable systems. Just visit a hostile URL, and the machine is compromised - no download, no warning dialogue. Here is a video demonstrating an attack. Perhaps there are other attack vectors, but the browser is the most important by far.

  • Correct - the only way to be sure is to prevent browsers from calling Java (by disabling the browser helpers, or uninstalling Java entirely)

  • The difference between 7u10 and 7u11 is described in the Oracle Update Release Notes. Summary:

This release contains fixes for security vulnerabilities. For more information, see Oracle Security Alert for CVE-2013-0422. In addition, the following change has been made: Default Security Level Setting Changed to High

scuzzy-delta
  • 9,303
  • 3
  • 33
  • 54
  • 1
    In the Internet Explorer of Microsoft you have to delete java from your computer to be protected against this vulnerability. In firefox, chrome it was enough to disable the java plugin in the browser. german security news: http://www.heise.de/security/meldung/Gefaehrliche-Luecke-in-aktueller-Java-Version-1780850.html – Jan Koester Jan 15 '13 at 22:02
  • @JanKoester - Actually you don't. You can disable Java within Internet Explorer by using the Java Control Panel. What you claim used to be true, since were talking about Update 11, its not 100% not true. – Ramhound Jan 16 '13 at 17:11
1

Thanks @Ramhound for your comments.

Recommendations:

  • Always keep your Java up to date, of course.

  • Configure your system to always ask before running Java, and only approve this if you trust the author.

  • Learn the difference between approving Java applet to run in a sandbox (which actually works, most of the time), and approving a Java applet to run with full access to your computer.

700 Software
  • 13,807
  • 3
  • 52
  • 82