Lets talk about a variety of Mac OS X software called Input Managers.
In brief, an Input Manager is software that can affect other running applications. The original intent of Input Managers was to provide a means for customizing the operation of the keyboard and/or mouse to support things like locale-specific input behavior (treating keyboard input differently for different languages or regions) and software that aids handicapped individuals. The name “Input Manager” is thus appropriate for these intended uses. (Read more about Text Input Management.)
However, it wasn’t long before Mac developers found this to be a useful way to graft additional functionality into other applications. There are several OS X software products out there that are input managers which have little to do with input management (Inquisitor, 1Password, Chax are three that I use today). These products are typically unstable in nature, since they often times rely on undocumented aspects of the “host” application. But when they work, they can add real useful functionality to other programs.
The downside to Input Managers is that it is a tempting means for rogue software to exploit. One such example is the “Oompa-Loompa” trojan which surfaced about two years ago. This was a download that supposedly contained pre-release screen shots of OS X 10.5. It masqueraded the installation program as an image file, and when the unsuspecting user tries to view the file, it installs itself into the user’s “Input Managers” folder. It then can access any application that is run and affects iChat in particular, so that it tries to spread to others in your iChat contact list.
One of the changes in Mac OS X 10.5 (Leopard) was in how OS X dealt with Input Managers. The early rumors were that Leopard wouldn’t permit them to run at all. But after release, Leopard did run Input Managers, but only those that are installed in the system-wide “/Library/InputManagers” folder.
The distinction is this: before Leopard, if a user runs software that tries to install an Input Manager, there is nothing to stop it from installing one that is local to that user’s account (installing it to the “/Users/username/Library/InputManagers” folder). With Leopard, installation of an Input Manager requires system-administration rights (so the user is prompted to authenticate to permit the installation), and the Input Manager is installed to the “/Library/InputManagers” folder.
The authentication requirement is the key and is a welcome change. There should be some kind of barrier to install software of this nature. BUT, it is wrong for Input Managers to only be installable in a system-wide fashion.
Before Leopard, I always— always— installed Input Managers for my own account only. By doing so, I could always login as another user to disable them. Remember— by their nature, they are less stable, and can cause applications to crash. A common request of developers when reporting bugs in their programs is to disable any third-party Input Manager software to see if it resolves the problem at hand. I could do that by logging in under a different account before Leopard, but now I cannot.
Personally, I would have preferred that user-specific Input Managers were still supported, but also require an administrator’s password to install. So, you would have a path, perhaps like “/Library/InputManagers/Users/username”, which may even be symlinked to “/Users/username/Library/InputManagers”. I think this is a better option, than requiring Input Managers to be activated for all users of that machine.
Hopefully a later update or release of OS X will address this and restore the option of user-level Input Managers.
Posted on March 1, 2008 10:44 PM | Permalink
Tags: apple, macosx, security
TrackBack URL for this entry:
bradchoate.com/mt/feedback/tb/1420
This article was published on March 1, 2008 10:44 PM.
The article previously posted was Netflix adds insult to injury.
The next article is 7 days to go.
Many more can be found on the home page or by looking through the archives.
2 Comments
The thing is that Apple doesn't want to address this. It wants all these hacks to go away on their own since the technology used for its original purpose has been superseded and everything else is just used to duct tape things onto other applications. (They may be *useful* hacks and I use a few myself, but they still inject code into every Cocoa app, which isn't all that good from a security and stability point of view, and practically nullifies any upside to signed apps since you still can't trust that code.)
Letting InputManagers live to see another day was clearly a small concession, and the draconian rules work as a deterrent. Putting it in /Library was probably one way of making sure you had administrator privileges to install it. They need to be owned by root and have certain permissions too, but you can set any file you own to those.
Apple isn't interested in fixing this or any other problem, because Apple doesn't want them to keep living. I'm not exactly jealous of them right now since they'll have to kill off a useful but insecure venue for extending apps.
/Jesper (since, apparently, my OpenID name is just my URL; hmm)
I guarantee this will be gone by OS X 10.8, and thats only if they include it in Lion. Apple are dumb for thinking that forcing all input managers to have system wide acces constitutes as a 'fix'
Why do Apple think that asking for your password is anything more than a minor security step. Everything asks for a password these days, from accessing your mail, to moving folders on your account. People no longer equate password protection to potentially dangerous access, they just see it as an obstacle between you and what you were trying to do before it appeared.
Leave a comment