Are Input Managers the Work of the Devil?
The recent flap over the Leap-A malware raises the question of whether Mac OS X is fulfilling its promise as a rock-solid system with a stable, unmodifiable base (see "Two Mac Malware Threats Sighted," elsewhere in this issue). The straw man here is Mac OS 9 and earlier systems, on back through System 6. In those days, you may recall, users could install third-party files called INITs (or extensions) which loaded during startup and modified the behavior of the System. A malicious or buggy INIT could easily destabilize the whole computer or make applications behave in unexpected ways; this could be troublesome both for users, who might find the computer behaving mysteriously, and for developers, whose applications might crash through no fault of their own. If you can’t rely on the System to be the System and nothing but the System, what can you rely on? Unfortunately many third-party INITs were really cool and using them was irresistible. People used to manage the inevitable resulting problems through a mixture of guesswork and extension managers, but we all knew, as four rows of INITs marched proudly across the screen during startup, that we were lucky if the computer worked at all.
In Mac OS X, on the other hand, there are no INITs, and the system files are protected by permissions. Thus, in theory, Mac OS X is much less susceptible to customization than earlier Apple systems. That may be disappointing (personally, I’d kill for a Mac OS X version of Menuette!), but the trade-off is the assurance that there is just one System – once I tell you what version of Mac OS X I’m running, you know exactly how it behaves in every fundamental respect.
But do you? I sometimes get the feeling that Mac OS X is just as full of customization holes as earlier systems were. In fact, Mac OS X may be worse than earlier systems, because those customization holes are harder to track than INITs were, and because the feeling of security misleads the user into a misplaced confidence. In reality, no one has a pristine System, and keeping the System even somewhat pristine requires constant vigilance. In an earlier article I talked about the security concerns represented by the Launch Services architecture and URL schemes (see "Explaining the URL-Based Mac OS X Vulnerability" in TidBITS-731). The Leap-A malware exploits a more insidious and powerful device, the Input Manager.
An Input Manager is, in theory, merely an aspect of text input. It is through an Input Manager, for example, that Japanese input is enabled on Mac OS X: effectively, the system watches as you type or work in the input palette, suspending judgment about the text being entered until you’ve supplied enough information, and thus you can enter characters from a repertoire vastly larger than the number of keys on a keyboard. Developers can create their own Input Servers, which embody the functionality of Input Managers and make themselves available to all applications.
<http://developer.apple.com/documentation/Cocoa/ Conceptual/InputManager/Tasks/ InputServerDeployment.html>
The trouble is that Input Managers "make themselves available to all applications" through being injected by the System into every application as it starts up. Thus an Input Manager is a general, legal method to modify application behavior. Naturally it didn’t take long for the thought to occur to someone that such modification need have nothing to do inputting text! Thus, Input Managers – or, at least, bundles of code installed in a Library’s InputManagers folder – are the basis of many popular hacks, including StuffIt Deluxe’s MagicMenu feature, CocoaGestures, Smart Crash Reports, certain Growl Extras, PithHelmet (and SIMBL), Saft, Inquisitor, and many others (as those last examples show, this is a particularly popular way to hack Safari). And Input Managers lie at the heart of how Leap-A works.
The reason this is such an easy vector for Leap-A to take advantage of is that no special permissions are required for an application to install an Input Manager into your ~/Library/InputManagers directory, nor (if your User is an admin, or if you give an admin password when requested) in the system-wide /Library/InputManagers. It can thus affect all subsequently launched applications, forever (or until you notice the unwanted Input Manager, delete it, and log out). It has been argued that this architecture represents no greater security hole than the maliciousness that any application might represent; after all, if I can get you to download and run my application, my application can delete everything in your User directory before you can say Jack Robinson. That’s true, but it’s also true that an Input Manager is code that you don’t consciously run. It blindsides you; it’s just "there," invisibly, affecting everything you do run, without your knowing what it does, where it is, or how it got there. Even in the absence of malice, a badly written Input Manager installed at a high enough level can render the computer completely unusable. Gosh, it’s just like in the good old days of System 6, isn’t it?
Unfortunately, it would require serious rethinking of the Mac OS X architecture to put this genie back in the bottle. Surely Apple has long known that Input Managers might be used maliciously; to do nothing about this possibility is to hope that they won’t be so used, and hope, while it may spring eternal, is not an effective security technique. Indeed, something suspiciously similar to Leap-A was announced as a proof-of-concept for the malicious use of Input Managers back in July of 2005; one can hardly be surprised at its present reification. (Even more suspiciously, the original article has been taken down.)
Before the identification of Leap-A, a discussion of Input Managers caught my attention because, embarrassingly, silent installation of an Input Manager is performed by Path Finder, an application that I had previously recommended. This discussion included various suggestions for coping with unwanted Input Managers, including simply locking down the InputManagers directories by assigning them prohibitive permissions. (Already there’s an "OompaLocker" AppleScript available to do exactly that.) Such measures seem extreme, but the chances that Apple will do anything to stem the spread of such unwanted silent installations are vanishingly small. So what’s a user to do? What I would ideally like is an application that would occasionally comb certain key folders (InputManagers, StartupItems, Extensions – any others?) to see whether anything has been recently installed there, and perhaps something that I could run before and after installing any new piece of software to learn what was installed where. (Yank is said to be an application of the second type, but I haven’t tried it.) Apart from that, I suppose we’ll all just have to keep muddling along as usual, hoping that Mac OS X is reasonably safe under most circumstances.