Safari: Swiss Cheese of the Internet

Posted on Tue, 19 May 2009
Landon Fuller posts a proof of concept attack using a publicly-disclosed Java applet vulnerability that hasn't been fixed on OS X.

Security is pretty much an all-or-nothing game. If there's a way in, you're insecure, and fixing all but one of the problems doesn't address the issue. Of course not every bug is created equal: some issues only let attackers go so far, while others allow full, arbitrary code execution. The easier it is to exploit a vulnerability, the worse it is. In this case, the ease of exploitation is very high due to the already released public details of the issue. It's also a logic error involving sandboxing, which makes it easier to exploit on all affected OS versions and processors than a buffer overflow vulnerability.

Browser-based vulnerabilities are particularly insidious because the browser is such a ubiquitous environment. Users visit untrusted pages with the confidence that they are protected from malicious content, but this confidence is misplaced. Visiting only trusted pages isn't an option either. Trusted web sites can be attacked and turned into infection-spreading vectors. Requests for trusted pages can be redirected by other systems on the local network as well.

The distressing fact is that users of OS X who browse with Safari have been vulnerable to browser-based arbitrary code exploits since the very first release of Safari in 2003. Several of these vulnerabilities have been slight variants of issues that Apple even attempted to fix. Naive design and poor testing is to blame. Apple has to start taking these issues seriously. That means fixing reported issues promptly before working on next-generation product features. It also means incentivizing researchers to report issues directly to Apple.

One of these days, someone will fall for the temptation to turn one of these exploits into a virus. It's simply too easy. There are no countermeasures built into the operating system, and it's easy enough to gain root access by hijacking calls to the authorization API (this isn't a security problem, according to Apple). Just add a rogue DHCP server that acts like the captive portals which are commonly found on open wireless networks, and any browser-based issue becomes a virus.

When that happens, short AAPL.

Trackback pings for this entry are listed below. The URL to ping for this entry is: http://brian.mastenbrook.net/trackback/32