MacForensicsLab, part of SubRosaSoft, has published a white paper on Mac malware (which it has the cheek to describe as an “academic white paper”; for the record it is clearly a commercial document not an academic one). The web version is uncredited, but the PDF (a whopping 50.2 MB!) appears to have been written by Marko Kostyrko, SubRosaSoft’s CEO.
The paper, broadly speaking, makes four key points, which you can find summarised at the bottom under the heading “For Apple, Inc.”. Of those four, controlling access to the address book is not a bad idea, nor is extending the sandbox system introduced in Mac OS X 10.5 (though it isn’t clear what the author means by including “code that is created locally”).
The other two points, arguably the most important, unfortunately don’t hold up to scrutiny:
1. Control the Bundle Architecture
“Apple might consider implementing a mechanism whereby a bundle cannot contain more than one executable for any given “Contents” subfolder. This would reduce the ability of malware authors to piggyback their code inside an otherwise legitimate bundle.”This idea is just plain ridiculous, especially for someone whose company sells utility software since utilities rely on the use of helper tools, which are auxiliary executables embedded in the application bundle that permit privileged operation. Furthermore, this restriction wouldn’t achieve anything (besides breaking a number of existing applications, that is). There’s nothing stopping a malware author from e.g. moving iTunes.app into /Library/Application Support and replacing it entirely, leaving only a single executable inside each bundle. Apple has already partially addressed the problem of maliciously altered applications by implementing support for code signing. If you attempt to modify a signed application as described earlier in the article, its signature will no longer match. It is true that Leopard presently does not inform the user if a signature is no longer valid. But it does restrict applications with invalid signatures in various ways, and, depending on the settings in the application’s Info.plist file, it can be configured to terminate applications that have been tampered with. If there is anything Apple needs to do here, it is to add a warning before launching a signed application with an invalid signature. Even then, it would only protect against modified apps, not against malicious apps dressed up as legitimate ones. The second part of this section says:
“Apple may also wish to discuss disallowing multiple extensions inside a .app bundle. This would reduce the ability of malware authors to disguise executable bundles as data files for their pro tools.”I assume Kostyrko means that Apple should disallow application bundles with multiple extensions, since he believes that Mac OS X will hide the “.app” extension. (For reference, when writing an academic paper, it is a good idea to get your terminology right, which would have avoided any doubt here.) Well guess what? Apple has already addressed this. If, on OS X 10.5, you take an application and try to rename it to have two extensions, Finder will display both extensions, even if the bundle has its “hide extension” property set.</li>
2. Control Write Access to the Applications Folder and Subfolders Found Therein
“The programs (commonly known as Applications) that a user relies upon… are stored unprotected inside a folder called ‘/Applications’. Any program running on a Mac OS X system can write to this folder and to most of the contents therein”and
“Apple may think about making it the default behavior for the system to require admin access to write to this very important folder. Furthermore Apple should make an interface that is easy, obvious, and non-technical to turn this access control on or off.”Sorry Marko, yet again I have news for you. OS X already does this too, and the Applications folder is not as you erroneously claim “unprotected”. If you use a non-administrator user, you can’t modify the Applications folder, and furthermore, if you try, Finder will offer an authentication dialog so that you can make changes if you know an administrative username/password. A lot of users of existing OS X use administrative users day-to-day, certainly, because that’s what the OS X installer creates for you automatically. But there’s nothing stopping you from going to System Preferences and making an additional, non-administrative user for day-to-day use. Indeed, if you’re reading this and you haven’t already done so, I encourage you to do just this. Helpfully, most OS X software works just fine from a normal user account, unlike the situation on Windows where there was and probably still is plenty that requires you to be logged-in as an admin user just to run it. Update (2008-03-07): Stéphane Sudre just pointed out that a lot of apps install into /Applications with the wrong permissions, either because of broken installers or because they’ve been installed using drag & drop. This is a fair point, though looking on my system I can only see a small number with suspect permission settings. I’d be interested to know what the exact deal is with drag & drop install and permissions; I’m not sure I know OTOH exactly how that works and I probably should :-)
Not only is the paper inaccurate, it is full of needless scaremongering, with sections titled “Macs Are Vulnerable” and “Complacency” as if to emphasise the author’s opinions and quotes from analysts about how “most Mac users take security too lightly”. Some of these sections are even written in the present tense, as if there is a significant amount of malware already in the wild. Thankfully there is not.
I find the entire thing particularly irritating, to be frank. The methods of product promotion used by the security software industry have often been criticised in the past, but dressing this lightweight marketing exercise up as an “academic” paper? Even without the inaccuracies and the needless scaremongering, this wouldn’t be published by any reputable academic journal.
Anyway, the best thing you can do for now as an end-user is to make yourself a non-admin account to use day-to-day, and to ensure that you keep regular back-ups of data you care about. Using a non-admin user will make it difficult for malware to affect applications installed on your machine, and keeping backups of critical data means that if the worst ever did happen, you could wipe the system and start again without worrying about losing data.