You know, it's fine to make the argument that "Macs are safer than Windows-based PCs," because in real-world usage, this is generally true. Nothing does more to undermine that argument, however, like a five-month old unpatched Java vulnerability.

As Landon Fuller has pointed out, a potentially nasty Java exploit remains unpatched in Mac OS X, including last week's OS X 10.5.7 update. Essentially, this exploit can allow malicious code to run outside of the confines of Java, and run arbitrary commands with whatever user permissions the logged in user has. So just by visiting a website, you could be allowing malicious software access to running commands on your system. Not cool. Not cool at all.

Although the exploit was initially discovered and filed back in August of 2008, Sun issued its own fix addressing the exploit back in December.

So, five months, two point OS updates, one Java update in February and stil, Apple hasn't patched the exploit on their end.

Can I just say, "WTF?" I mean, seriously, get on the ball Apple. You only have $20 billion in cash, maybe investing in a bunch of full-time security patchers for your operating system would be a worthwhile investment!

Julien Tinnes has some excellent commentary on the exploit here. As Landon says on his blog, all users are advised to disable Java applets in their browsers and disable "open safe files after downloading" in Safari. You should also consider using a SSB (site-specific browser) for any Java-crucial web work (see below).

Of course, being forced to disable Java applets just so one can ensure safety kind of puts Mac users who, I don't know, use a web-based SSL VPN client to connect to work systems or e-mail in a bind.

And, let the flogging from the Apple-haters commence.

This vulnerability is patched in the 2009-001 security updates.

When reports of security issues in Apple's Safari browser come over the transom, they get our attention. When they're exploitable in both the Mac and Windows versions of Safari, they get our full and undivided attention. When the person reporting them is Brian Mastenbrook (credited with discovering multiple previous vulnerabilities in Mac OS X)... well, someone shut off that damn klaxon and let us get back to work. In this case, the issue is that a hole in Safari's handling of RSS feeds could allow an attacker (via a malicious web page) to capture a user's personal information, cookies or even passwords.

While Brian has not posted more details of the vulnerability publicly, he has acknowledgment from Apple that the issue exists; hopefully we will see an update soon that closes this hole. In the meantime, although Windows Safari users are advised to use a different browser to avoid the vulnerability, Mac users can simply set an alternative RSS feed handler to work around the issue.

Update 1/14: Per Brian's further research, the workaround below is not adequate to protect against the vulnerability, as Safari also handles URL types of 'feeds' and 'feedsearch,' which cannot be set to alternative handlers within Safari itself. The revised workaround calls for the RCDefaultApp preference pane, which does let you redirect the other URL types.

To change your feed handler, go to Safari's Preferences and click the RSS button. If you have any other capable feed reader on your machine, you can select it from the list (if your menu looks like mine does in the screenshot, you have a serious problem with RSS reader addiction and you need immediate help). Don't have another feed reader available? NetNewsWire and NewsFire (and the open-source Vienna, cited repeatedly by our commenters) are free for the downloading, as is the Reader Notifier helper app that interacts with Google Reader -- for the purposes of getting around the vulnerability, it doesn't matter which application you choose as long as you don't leave it set to the default of having Safari do its own RSS chores. Note that the vulnerability apparently does not require you to open a feed in Safari to be affected -- a specially-constructed webpage is capable of triggering it.


RCDefaultApp settings for "feeds" and "feedsearch" also need to be modified.

Thanks to Brian for the heads up & everyone who sent this in.

The distance between good intentions and actual results seems to be getting longer and longer. While Apple did release a security patch yesterday that included a fix to BIND for the highly publicized cache poisoning exploit -- some time after most other vendors got updates out to customers -- that fix doesn't seem to be, you know, actually working.

Multiple sources have noted that Apple's DNS patch, at least on Mac OS X 10.4 and 10.5 client versions, isn't implementing the key feature that's meant to block cache poisoning: port randomization on requests. While the same version of BIND running on Linux systems behaves as expected, Mac OS X machines doggedly issue DNS requests on sequential ports, making them far more vulnerable to spoofing by malicious folk.

This may seem like an esoteric vulnerability, and indeed for most Mac users the more important question is whether or not your ISP or network manager has patched the primary DNS servers you rely on (you can check your DNS server status via Dan Kaminsky's tool here). The behavior of Apple on this security issue, however, is very troubling. Waiting weeks to issue a patch for a key vulnerability and lagging behind other OS vendors is bad enough; shipping that patch only to have the user community discover that it doesn't work worth a bucket of warm spit ... that's not the act of a company that claims to care deeply about the security of its customers.

Update: Kaminsky suggests that we lighten up; Mac OS X Server (which would be the most vulnerable to attack, if it serves as the primary DNS for your network) has been patched, even if the client patch isn't behaving properly yet.

According to Matasano (home base for security researcher Dino Dai Zovi), the announced-but-unreleased web browser exploit that was used to win the CanSecWest MacBook Pro challenge involves browser support for Java. Turn off Java for Safari (or Firefox, or Camino) and your machine is immune.

Let's take a moment to note, before frantically shutting down all the garbage mashers on the detention level, that this is an unreleased exploit and there is no expectation of it going wild; it's in the care and feeding of the Zero Day Initiative now and notification to Apple, Sun (Java) and other affected parties will be handled professionally. The only real-world risk is if some clever soul manages to find the same unpublished vulnerability that Dai Zovi did and pairs it with a malicious payload. Personally, I use Java for a couple of work purposes, but I can presumably leave it on in one browser for those specific pages and do my general browsing with another, Java-disabled browser... that is, I would, if I was paranoid.

There are plenty of other ways to improve your Mac security, most listed via this post. Top three: turn on the firewall, run as a normal user, and turn off wireless (at least, turn off automatic connection to open networks). Apple's guide to Tiger security is also available as a PDF here.

The UK's IT Week reports on a possible new Mac OS X exploit. A proof of concept appears on the Info-pull.com website, claiming that corrupted UDTO HFS+ image structures are vulnerable to denial of service attacks. If true, this same issue may affect FreeBSD installations. The article suggests disabling "open 'safe files' after downloading", which realistically speaking you've probably already done a long time ago if you've been worried about possible OS X attacks.

I take security exploits seriously. I'm responsible for many hundreds of Macintosh computers that reside in many different environments, not to mention half-a-dozen X-Serves, several of which are production boxes open to the world. When a security exploit is announced, I look to see if it will impact my workstations and servers and whether I need to take immediate action. And with the exception of the recent Safari exploit that was patched last week by Apple's Security 2006-001 Update, there hasn't yet been a single vulnerability that significantly affects my computers' operations. [Note, reader Brent points to a ZDnet article just published a few hours ago that claims Apple hasn't adequately fixed the Safari exploit in question].

So when an article claiming "Mac OS X hacked in less than 30 minutes" popped up on my news radar last night, I read through it and quickly dismissed it as a non-story, and a journalistically unsound one at that. Neither this article or any of its copycats (up to more than six now), has bothered to even attempt to actually explain the "hack" or the "exploit." Plain and simple, folks, these articles are full of hype, empty of facts, and are bunk: