Mac OS X Users Vulnerable To Major Java Flaw

FruitWorm writes in with word of a vulnerability in Java that has been patched by everyone but Apple. "Security researchers say that Mac OS X users are vulnerable to a critical, 6-month-old, remote vulnerability in Java, a component that is enabled by default in Web browsers on this platform. Julien Tinnes notes that this vulnerability differs from typical Java security flaws in that it is 'a pure Java vulnerability' and doesn't involve any native code. It affected not only Sun's Java but other implementations such as OpenJDK, on multiple platforms, including Linux and Windows. 'This means you can write a 100% reliable exploit in pure Java. This exploit will work on all the platforms, all the architectures and all the browsers,' Julien wrote. This bug was demonstrated during the Pwn2own security challenge this year at CanSecWest, but the details were not made public at that time. Tinnes recommends that Mac OS X users disable Java in their browsers until Apple releases a security update."

Comments

Design or implementation flaw?

[pwilli]

I'd really like to know if this was/is a flaw in the structure/design of the JVM or just happened to be some kind of pitfall every major JVM-implementor fell into.

The articles and bug reports are light on detail, I could only find out it is related to "Deserializing Calendar Objects" and allows the applet to execute stuff with the users rights (or probably more correct, the rights of the webbrowser who started the applet)., which sounds like an implementation problem to me. Was there some reference implementation all JVM-developers used for this specific functionality?

Re:Design or implementation flaw?

[QuoteMstr]

technical details here.

The gist of it that the Java Calendar code temporarily elevates its privileges in order to deserialize a ZoneInfo object. If you substitute your own object's serialization for the ZoneInfo, you can get the Java runtime to create any object you want. Some questions:

1. Didn't anyone realize how dangerous arbitrary privilege elevation is?
2. Didn't anyone think that it might be overkill to elevate privileges in order to read a timezone?
3. How many other similar vulnerabilities are lurking in the standard library?

To be expected

[Shrike82]

The (untrue) assumption that many people seem to hold that Macs are just invulnerable to anything bad happening has finally spread to Apple itself, and they're the last to patch this exploit. Since a lot of Mac advertising used to be based on "Macs don't get Viruses" you'd think they'd have been the first to patch this to maintain their reputation.

Yes I know I'm probably going to get modded down immediately for saying this, but hell, it's the truth.

Re:To be expected

[oDDmON oUT]

"The (untrue) assumption that many people seem to hold (is) that...", patching actually is a "best practice", when it's not.

Marcus Ranum has a interesting and humorous take on patching that spells it out much better than I could.

The short version:

• Patching is a substitute for good design
• Patching exists for the simple reason that there is a rush to get products out the door, rather than take the time to ensure that they are secure

This is true of 99.9% of software in use.

Oh I don't know...

[Shivetya]

after meeting some Mac newbies I am think I can already see the iceberg. Two are friends, one of which called me out of the blue to tell me that he just bought his first Mac (an iMac actually). Well needless to say I get calls from both since I am the "mac expert" (Read: I had one longer than them).

The simplest way to say it, they are more than happy to key in their password for anything that asks, even if they don't know what they are doing. After all, they are on a Mac, they don't have virus protection because it doesn't need it, so how is something bad going to get on the system. These are not normally dense people, well maybe they are proving me wrong.

So I figure that someone out there will rely on this type of stupidity to get key loggers, bots, and the like, on Macs. The number of people out there who buy one because they think it makes them cool or smart cannot be underestimated.

I do know one of these two did ditch firefox because they didn't like clicking the ad-block button to allow some sites. So it is just a matter of time.

(and no, I do not run a AV or worry about it on either of my Macs)

Re:Java and not javascript

[kthreadd]

I'm more inclined to let the company that specializes in that stuff deal with it - but then again, maybe it gave them much needed experience for their Rosetta technology

According to the Sun engineers I've talked to it all has to do with a really old license agreement between Apple and Sun that they can't change for now. Sun is forbidden to directly release Java for Mac OS X until the agreement expire or Apple decides to make a new agreement. The only practical solution they proposed was to use the BSD port of OpenJDK. You won't have the Aqua UI and I think you have to deal with X11, but you will have an overall better Java.

Re:apple letting down java users..

[cshbell]

I don't see the point you're making. You might as well have contrasted nine-year disparate statements about RAM size. Over nine years, Apple's stance towards Java has changed; what's wrong with that? In 2000, Java seemed to have a wider path on the desktops than it does in 2009. Other languages and runtime environments have grown up around Java in the subsequent nine years, and to Apple's thinking, the other languages (such as Objective-C 2.0) allow for building better software than Java allows.

Apple's stance appears to be, right or wrong, that Java on the desktop and mobile devices is no longer the best way to develop and deploy software, and thus, they've allowed the Java implementation in OS X to grow long in the tooth, and have outright declined to port it to the iPhone/iPod Touch OS.