Terminal Security¶
1099 words on Mac OS X
Ugh. A potentially quite serious OS X security problem has been discovered. [Just read those and the links in them as I won’t regurgitate the whole story here once more. ]The bottom line seems to be that due to several somewhat carelessly designed bits of OS X working together, it can happen that a file you download or received by Mail is passed straight to the Terminal for execution. That, of course, can be quite dangerous.
As this problem involves many parts of OS X, ranging from a receiving application like Safari or Mail to Launch Services to the Terminal application, it is a bit difficult to see where things go wrong exactly and where the security problem has to be fixed.
While everybody will agree that it’d be good to get a fix for this from Apple quickly to avoid malicious exploits, I think for the long term it’ll be as important for the problem to be analysed and solved properly. Where exactly are things going wrong? How can this type of exploit be avoided in the future? With many different parts of the OS being involved in this and Apple’s documentation not exactly being existant that’s hard to tell from the outside… but let’s hope somebody actually knows what’s going on.
The knee-jerk reaction to this might be to kill Safari’s very handy auto-expansion feature or to automatically kill the manually set ‘open with’ settings of files when they’re received from the outside. I doubt that these are solutions to the problem. They’d just make it harder to exploit and add extra inconvenience for the user. My Macs have been automatically decompressing whatever they downloaded for the past decade and I don’t want to change that.
Looking at the technical side, i.e. the resource that is used to set the preferred application for opening a file, it is a bit baffling to see that it relies on an absolute path. Meaning that renaming or just moving an application will break all the custom ‘open with’ settings you made to your files. I mean, there are aliases and bundle identifiers and even creator codes. A combination of those should be able to pin down the application in a much more reliable way. The irony is that this design flaw of the custom application setting can work for you here, as a simple move or rename of the Terminal application will break the reference to it (and – keeping in mind that Apple’s installer / update mechanisms are pretty close to braindead – will make sure that your ‘cleverness’ in doing this will haunt you at some future system update.
My impression is that partial blame for the problem is with Launch Services. While this is not be the main issue here, they seem to automatically provide a safe looking icon for a file (say an iTunes MP3 icon) even when it is set to open with Terminal (which doesn’t provide an MP3 file icon). This makes things look prettier – but it’s also a bit sloppy. However, I doubt that it’s crucial for the security situation here as you can easily stick a custom icon to a file anyway. (See my infamous make your own ‘virus’ post for an example.)
What seems to be the problem here is the ‘small pieces loosely joined’ approach OS X takes. A file is received by some piece of software, some security checks are done, then another piece of software is told to open it with yet another piece of software. And in that process some crucial security-related information is lost. Information for opening the file is taken from different places, not all of which are evaluated in each step of the process. Most likely, Safari just uses the solely UTI based Download Assessment settings to determine its file handling. And those, being based on the UTI of the file alone, ignore the additional information on the application that’s going to open the file.
Again, I don’t think this is a bad idea per se. If only because it’d be pretty hopeless to come up with a sufficiently general way to handle all possible applications that could be set up without being terribly annoying.
Thus, to me it looks like Safari and Launch Services may be a bit sloppy in places but aren’t doing fundamentally wrong things. Which leaves us with the Terminal. Despite being an application that is known to be potentially harmful, the Terminal doesn’t seem to do any checks on the file it opens. Basically you can tell the Terminal to open any file on your hard drive. (Do this by command-option dragging the file to the Terminal icon, by using the Open With command and many clicks in the Finder or by using the open command on the command line.)
And as long as you have ‘x’ permissions for that file, the Terminal will run it. As demonstrated by this little exploit, blindly running any file that’s passed to it. Thus, the Terminal will run any file it is told to run as long as it can do it. No matter how the file is passed, what type it is of, and who passed it. While because we can
may be a catchy line for a Stevenote, it looks more than just a bit careless in real life. And that’s a shame.
Particularly when recalling that the Terminal took centre stage in a previous, very similar, Mac OS X security problem. So you would’ve hoped the Terminal people had learned some lesson back then – but apparently they just fixed the obvious problem and were then told to do something more important, like generating Dashboard widgets.
So while this may not be a completely satisfactory cure for all possible problems of this kind, it seems that applications should be a bit careful with the files they open. And that’s particularly true for applications like the Terminal where the content of the file they open can affect things other than that file itself. Some checks of files the Terminal is told to open are in order. For example, if the Terminal is asked to open a file that doesn’t have a Terminal UTI, it could ask the user whether that was an intended action.
Apparently there is now an InputManager to install on your system that keeps the Terminal from running any file it’s told to open. Good for those who don’t want to rename their Terminal application and prefer to lean back and enjoy one of those dangerous Input managers doing its magic – along with the irony.
