Apple Patches Security Holes in Java for Leopard, Snow Leopard

| Product News

Apple released Java for Mac OS X 10.5 Update 10 and Java for Mac OS X 10.6 Update 5 Tuesday, both of which update Java SE 6 to 1.6.0_26, while the Leopard patch also addresses issues in Java 1.5.x. In both cases, however, “multiple vulnerabilities” in Java are addressed in the updates, several of which could allow the bad guys to gain control of your Mac.

Java for Mac OS X

The releases notes for the update specify only the update of the update to Java SE 6. The security notes, however, detail the fixes included in the update(s).

First, the Leopard security notes:

Java for Mac OS X 10.5 Update 10

  • Java
    • Available for: Mac OS X v10.5.8, Mac OS X Server v10.5.8
      Impact: Multiple vulnerabilities in Java 1.6.0_24
      Description: Multiple vulnerabilities exist in Java 1.6.0_24, the most serious of which may allow an untrusted Java applet to execute arbitrary code outside the Java sandbox. Visiting a web page containing a maliciously crafted untrusted Java applet may lead to arbitrary code execution with the privileges of the current user. These issues are addressed by updating to Java version 1.6.0_26. Further information is available via the Java website at http://java.sun.com/javase/6/webnotes/ReleaseNotes.html
      CVE-ID
      CVE-2011-0802
      CVE-2011-0814
      CVE-2011-0862
      CVE-2011-0863
      CVE-2011-0864
      CVE-2011-0865
      CVE-2011-0867
      CVE-2011-0868
      CVE-2011-0869
      CVE-2011-0871
      CVE-2011-0873
  • Java
    • Available for: Mac OS X v10.5.8, Mac OS X Server v10.5.8
      Impact: Multiple vulnerabilities in Java 1.5.0_28
      Description: Multiple vulnerabilities exist in Java 1.5.0_28, the most serious of which may allow an untrusted Java applet to execute arbitrary code outside the Java sandbox. Visiting a web page containing a maliciously crafted untrusted Java applet may lead to arbitrary code execution with the privileges of the current user. These issues are addressed by updating to Java version 1.5.0_30. Further information is available via the Java website at http://www.oracle.com/technetwork/java/javase/documentation/overview-137139.html
      CVE-ID
      CVE-2011-0802
      CVE-2011-0814
      CVE-2011-0862
      CVE-2011-0864
      CVE-2011-0865
      CVE-2011-0867
      CVE-2011-0871
      CVE-2011-0873

Lastly, the Snow Leopard security notes:

Java for Mac OS X 10.6 Update 5

  •  
    • Available for: Mac OS X v10.6.6 and later, Mac OS X Server v10.6.6 and later
      Impact: Multiple vulnerabilities in Java 1.6.0_24
      Description: Multiple vulnerabilities exist in Java 1.6.0_24, the most serious of which may allow an untrusted Java applet to execute arbitrary code outside the Java sandbox. Visiting a web page containing a maliciously crafted untrusted Java applet may lead to arbitrary code execution with the privileges of the current user. These issues are addressed by updating to Java version 1.6.0_26. Further information is available via the Java website at http://java.sun.com/javase/6/webnotes/ReleaseNotes.html
      CVE-ID
      CVE-2011-0802
      CVE-2011-0814
      CVE-2011-0862
      CVE-2011-0863
      CVE-2011-0864
      CVE-2011-0865
      CVE-2011-0867
      CVE-2011-0868
      CVE-2011-0869
      CVE-2011-0871
      CVE-2011-0873
  • Java

You can download the updates through Software Update. the Snow Leopard update is a 78.9MB download.

Sign Up for the Newsletter

Join the TMO Express Daily Newsletter to get the latest Mac headlines in your e-mail every weekday.

6 Comments Leave Your Own

archimedes

It’s annoying that after 16 years of Java development, its sandbox still doesn’t work. This is why Java remains disabled in my web browser.

Of course, even if you disable Java, it’s almost certain that similar unpatched bugs remain in *JavaScript*, which is used on nearly every web site; this is why NoScript is not a bad idea, though it doesn’t solve the root problem, which is that it’s very hard to safely execute untrusted code.

The near inevitability of bugs that allow browsers to be compromised by malicious code or data is a compelling reason for running Chrome or another browser where individual tabs run as separate processes that are themselves sandboxed using features that are part of OS X itself. This means that even if an individual tab is compromised, it should not be able to read or write files outside of your Downloads folder, for example, nor will it be able to read data from another tab which is connected to your bank.

Substance

Java and JavaScript have almost nothing in common beyond their names and syntax.  As far as programming languages go, they are about as far from one another as you can get.

archimedes

Java and JavaScript have almost nothing in common beyond their names and syntax.  As far as programming languages go, they are about as far from one another as you can get.

As far as runtime behavior is concerned, Java and JavaScript have much in common, and that is precisely the problem.

They both:

1. Download untrusted code and run it in your browser.
2. Use a virtual machine to execute such code.
3. Use a just-in-time compiler to dynamically translate bytecodes into machine instructions.
4. Rely on security policies in the virtual machine to restrict what code can do.
5. Allow access to the browser DOM
6. Have been the source of numerous security bugs which lead to arbitrary code execution within the context of a web browser.

See the similarity - and the problem - now?

Regarding language design, although Java and JavaScript have very different APIs and object models (e.g. classes vs. prototypes), they are both:

- C-like in syntax (as you noted)
- dynamic languages
- semi-closure-capable (JavaScript having real closures while Java has inner classes, last I checked)
- dynamically bound and typed (although Java supports static typing as well as dynamic typing)
- derived to some extent from Smalltalk-80 (e.g. object-based, dynamically bound, bytecode-compiled, etc.)

That’s quite a bit in common, and a far cry from “as far from one another as you can get.”

Most importantly, back in the 1990s, Java was intended to facilitate rich client apps inside the browser - and it still does, to some extent, but that functionality has been almost entirely replaced by JavaScript. Nonetheless, the idea of downloading untrusted code into your browser and executing it is inherently perilous, and leads to the numerous bugs we’ve seen in Java, Flash, JavaScript and even other sandboxed browser-based virtual environments such as Google Native Client.

archimedes

Actually, I believe that Safari has improved the way it handles plug-ins, and they are now run in a separate process, WebKitPluginHost. This makes it harder for them to corrupt or crash the browser (though they still have DOM access), and is why the numerous Flash crashes no longer crash Safari.

I believe JavaScript still runs in Safari itself (it certainly does on iOS); this makes it in some sense more dangerous than Flash or Java, which are plug-ins.

Of course, dynamic code is not the only source of exploits; buggy handling of HTML, CSS and binary data such as images are other frequent sources of browser security holes. This is another reason why Chrome’s sandboxed process-per-tab model makes sense.

Substance

@archimedes, you missed my point.  An update to the JVM on Macs has nothing to do with JavaScript VM that is used by your Web browser.  So lumping them both together as youd did in your first post felt misleading.  Fixing issues in one will have no effect on the other.

And for the record, Java is a statically typed language.  And static vs. dynamic languages are about as far apart as you can get for languages that are in the same generation as each other.

discountcode17

apple always do some favor for customers ,this new feature for security is really nice

Log-in to comment