Rixstep
	`About \| ACP \| Buy \| Industry Watch \| Learning Curve \| News \| Products \| Search \| Substack`

Home » Industry Watch

NSWorkspace Corruption

Can lead to targeted attacks on OS X.

Get It

Try It

There's a serious bug in NSWorkspace code for OS X. It was introduced in version 10.6 and has only got worse, and it's so bizarre that the possibility it's intentional cannot be completely dismissed.

The issue concerns three methods in the NSWorkspace class.

-[NSWorkspace iconForFile:]
-[NSWorkspace openFile:withApplication:]
-[NSWorkspace getInfoForFile:application:type:]

The first two methods listed above perform correctly. Their behaviour hasn't changed. It's the behaviour of the third method that's suspect.

-[NSWorkspace getInfoForFile:application:type:] is used to determine, before opening a document, what application will be used to open it. Obviously this is critical code: Apple have had a safeguard against downloaded trojans introduced in this way for ten years.

Circumventing this code was how the Oompa Loompa trojan worked. It was disguised as a GZ archive but was actually a shell script that took over the local machine.

The three above methods should be using the same base code. This was probably the way it started out back at NeXT prior to 1997. All three methods have to access the application designated to open a document. The first method wants to find the icon used to signify the document. The icon used will be specified in the Info.plist file of the designated application.

The second method will work correctly even today. But that's actually cause for alarm. It means not only that the base code for these three methods has been forked, creating the dangerous situation of today, but that whoever altered the code of the third method somehow did not ruin the code that actually opens documents. That's either incredibly stupid or dangerously malicious.

The third method is the black sheep. This is the one that returns incorrect information. It worked fine with 10.4 and 10.5, but starting in 10.6 it began acting up. With 10.6, it got so confused that at times it returned nothing at all.

Testing NSWorkspace 10.4-10.6

Testing on 10.4. 'link1' has a screenshot (format PNG) as its target. -[NSWorkspace getInfoForFile:application:type:] correctly finds the default application to open the file (Preview.app).

Testing on 10.5. 'link1' has a screenshot (format PNG) as its target. -[NSWorkspace getInfoForFile:application:type:] correctly finds the default application to open the file (Preview.app).

Testing on 10.6. 'link1' has a screenshot (format PNG) as its target. -[NSWorkspace getInfoForFile:application:type:] fails miserably - it's not capable of returning anything.

Things continued to roll downhill with 10.7 when it was discovered that -[NSWorkspace getInfoForFile:application:type:] turned focus onto the symlinks themselves, resulting in completely misleading information.

The alert user might suspect something is wrong if viewing files in a file manager with icon representation, but the odds are about as good as they were for users hit by the infamous ILOVEYOU worm: you have to notice the icon isn't what it should be.

The code for the second method (-[NSWorkspace openFile:withApplication:]) is not easily fooled. You can test this by creating symlinks to authentic files and then creating symlinks to the symlinks, and the method will still figure out where the correct application is. Likewise with the first method which just as accurately can find the icon.

But the final method produces stupendously sophomoric results. The method should never look at the symlink per se, but the code in use today not only looks at it, but picks up associations from the file extension. Things can't get crazier than that.

The correct icon is always returned - and the fortunate user, especially if having read this article, will raise an eyebrow when the system says something else. And the correct application will be used to open the document. But that's the problem: that 'correct' application might not be one you like.

The system can be fooled into giving you false information about what's going to happen when you open a document. Altering the file extension on a symlink can give you deliberately incorrect results (rather than as in 10.6 where you get no results at all).

Here's the default situation today with 'link1' pointing to a screenshot (extension and format both PNG).

Now change the name of the symlink to give it the 'app' extension.

Now change the name of the symlink to give it the 'mov' extension.

Now change the name of the symlink to give it the 'txt' extension.

It's well known that the code for the launch services, which governs methods such as those in NSWorkspace, is getting more buggy and corrupt by the day. But would anyone be dumb enough to fork code that's run perfectly well for 15-25 years?

It's known today that Apple collaborate with the NSA. They're a part of the mass surveillance program known as PRISM. This isn't something the fanboys like talking about too much. But it's there.

It's also known there are other technologies in use by the NSA provided by third party vendors. Many have been exposed in the 'Spy Files' releases by WikiLeaks.

One of the recurring claims is that these corporations can compromise any system, and not just Windows. One of the recurring questions in that regard is how such a thing would be possible. OS X is secure, isn't it? It's a Unix, isn't it? It's built on a 'rock solid foundation', isn't it? It's not a Windows!

True enough. But if (deliberately) incorrect NSWorkspace code can be used to mislead a system (or a user) into thinking a program launch is innocuous, then trojans as used by the NSA and their friends can be installed on a Mac without the user's knowledge. And then the claim by FinFisher and others is true.

And as has been said so often at this site, it's one thing to have somewhat shaky code in the nascent period for a new system. NeXT might have had that back in the 1980s. But not when they merged with Apple in 1997.

For it's a whole different situation when a clumsy corporation can take someone else's stellar code and systematically ruin it.

We who've stood by and watched Apple ruin the NeXT legacy all these years know what's going on. But the thought this may have been done intentionally is a new twist.

Dare One Hope?

Too many screwy things have transpired in the years since Apple took over the NeXT code. Tableview interaction is completely destroyed and affects every application in the system, Apple's as well as everyone else's. To hope Apple will do anything for this bug is to hope too much.

Third party vendors are tired of introducing band-aid code to compensate for failures at Apple that are caused by Apple but never fixed by Apple. Just invoke the info sheet and be very observant of the document icons you see. Reboot regularly as Apple also screwed up the launch services beyond repair, with so many bugs in there today it's not funny. And use Tracker for all new applications. Your OS vendor let you down.