theReformed

Apple’s OSX iterations have been known to be some of the more securely designed operating systems on the planet. There is no real threat from viruses under OSX because of it’s strict use of access rights, built into it’s BSD base which regulates the access rights of every user on the system. However, basic security in their user interface could be compromised by a very simple, very useful feature known as “Spaces“, a feature lifted and rebranded from X Windows and Amiga (reference: Wikipedia), through a plausibly effective and relatively controversial Denial of Service from within the user interface. I got to scratching my head when playing with this feature realizing it’s potential flaw is so simple, its almost idiotic and so far as I can ascertain, overlooked or ignored.

(NOTE: Updated to include a reference to a trojan recently released for OS X that similarly mimics the behaviour discussed here originally in May)

The premise of this theory is that Spaces is a means of virtualization of the desktop, wherein users are able to have multiple desktops hosting multiple applications in each window without the need to cram everything you’re using onto one screen by itself at any given time. On one desktop or Space, I could have Adobe Photoshop CS3+ running, iChat on another and the next I could be using Microsoft Entourage to check my e-mail. Three separate Spaces have expanded my desktop now from 1280×1024 to 1280×1024x3 (up to 16 Spaces are allowable according to Apple). The possibilities of efficiency with this are endless, however, there is a problem.

Spaces inherently has a function to where the user is able to switch between Spaces based on a set of key combinations such as how I picked the Command and Arrow keys to swap between my Spaces - in succession, I can hold down the Command+Right Arrow and swap between all three Spaces, one right after the other - a behavior I stumbled on though has alarmed me. Spaces has a hook in place by default and with no apparent trigger to disable it from the Preference Pane, where if I receive a instant message via iChat, I will switch from one Space to the next Space that hosts that iChat application.

So, although I currently have not had a chance to write/provide a proof of concept yet (if someone would like to write one I will be happy to post it here for review) due to schedule constraints, there is a underrated Denial of Service to the user interface itself available here for exploitation by any software engineer ept enough.

I imagine the scenario to playout like this:

1. A well-looking exploit wrapped in eyecandy is installed unwittingly by the user who will undoubtedly have to enter the Administrator password to install the application on OSX (the standard operating procedure by which all major installations are made on OS X it would seem) - providing this hasn’t been disabled by either the user or the software itself. This has been proven realistically possible by the ARDAgent Trojan for OS X.
2. The exploit is either run by the user or is loaded as a service, possibly on boot from …/com.apple.boot.plist or something of a similar nature.
3. The user logs into their desktop profile as they normally would on any given day.
4. The exploit, sensing the login, triggers the involuntary hook that iChat and other numerous applications use to swap between desktops, one after the other, consecutively where “Force Quit” is useless to stop it since it does not load atop the desktops themselves, but announces itself within the Space windows.
5. The involuntary action continues until the user reboots the system, only to encounter the same issue when they login once again.

Anyone can test the basics of this scenario if they have an Apple or OSX on x86 hardware by logging in, setting up Spaces via the System Preferences and it’s associated Preference Pane and committing to the keys chosen multiple times - Spaces is apparently resource intensive enough to continue after you’ve stopped hitting keys, executing each successfully, but semi-involuntarily. This issue seems to be adding credit to the idea that perhaps Spaces is broken as Dave Dribin lends credit to in his weblog entry.

PROS: The unfortunate pro is that because Apple has concentrated on making the Mac as user-friendly to even the lowest layman (it just works), a large segment of it’s userbase would be effected because they are naive enough to go along with a professional looking installation - perhaps this exploit disguised as a free product to optimize their already fast Apple in the first place. Windows users have fallen prey to this very phenomenon, should we really assume Apple’s users are much different?

CONS: The cons of such a DoS would be that it isn’t effective against users who do not choose to use Spaces (it isn’t an option loaded by default) and there are several actions the user would need to take or the exploit author would have to change on default installation of the rogue application before the DoS would take effect. Additionally, the exploit author might have to somehow hinder the “F8″ enabling/disabling function for Spaces, which could be accomplished with minimal degree of effort.

The remaining question posed by a viewer, is whether or not this behaviour could survive the Single-User mode via whatever framework set it in motion. That remains to be seen.