The Hickensian

23.03.07 An end to Browser pimping?

20 comments
Tagged with: browsers, osx, plugins, security

Thanks go to Doug March, who pointed me to an article on Ars Technica on Leopard (Mac OS X 10.5). In particular, it was this paragraph that Doug wanted to draw my attention to:

“One more tip we got regarding Leopard, is that InputManager plugins are no longer allowed. That’s right… no more little hacks from anybody besides Apple. No more Apple menu hacks. No more Safari plugins.”

Oh shit! No more InputManagers = no more useful plugins like Saft or Inquisitor. OK, the use of the word ‘plugin’ is up for debate (Haxie is maybe a more appropriate term), but these are little caffeine boosts to apps with no plugin API, and I for one love them.”

The article continues:

“Apple isn’t really broken up about it since InputManagers were often used for nefarious purposes anyway,” our sources said, but the loss of InputManager control will break a lot of shareware and commercial software that currently makes use of that control.

It was news to me, but apparently InputManagers are a security risk. I was well aware of the chance of crashing and sluggish performance, but not malware using it to do BadStuff™ to your Mac.

What isn’t clear at this stage, is whether this applies to SIMBL, a method of applying hacks to a specific app. InputManagers load for every application, whether it’s intended for it or not, although not necessarily being active in those apps. SIMBL got around that and could be more targeted. I’ve asked Mike Solomon if he knows, but I guess until he gets his hands on Leopard, there’s no way to be sure.

It does mention that “InputManager is not exactly the same as APE, by the way”, so perhaps Unsanity’s APE (Application Enhancer) system could be used? I must say though, I’ve not had the greatest experience with their APE modules.

There is another way of course. Apple could develop a proper plugin API for their apps (Safari in particular), but something tells me that ‘giving up control’ is not something they’d want to do, and for good reason. As the Camino developers experienced recently, 3rd party plugins/hacks can really screw with day to day bug tracking and resolution.

Somehow, I can’t help feeling optimistic that someone somewhere will find a way, and a good way at that…

Comments | RSS

No.1

∞ Sam said 1054 days ago:

I sure hope that there is an alternate solution to the death of InputMangers. SIMBL hopefuly.

Not sure I could live without Inquisitor and my other haxies!

No.2

∞ Tim said 1054 days ago:

They’re going to take Inquisitor away from us? :’(

No.3

∞ Dan said 1054 days ago:

SIMBL is also an InputManager¹, unfortunately, so this would also not work if Leopard outlaws them.

[1] It is loaded into every application, just like other InputManagers. The difference is that SIMBL then only goes on to load its bundles within the application they specify.

No.4

∞ Doug March said 1054 days ago:

Well here’s to hoping this is just half the story. I also would be lost without the haxies

No.5

∞ Doug March said 1054 days ago:

Let’s hope they have an alternative that is less “nefarious”

No.6

∞ Eric Schwarz said 1054 days ago:

If that is the case, I’d switch to Camino (or even Firefox) because I don’t have a pimped out Safari, but I do like a few of my plugins…

No.7

∞ Geof Harries said 1054 days ago:

I love me some Safari, but I respect Camino and Firefox more because they’ve purposely built extensibility right into the browser.

No.8

∞ Anthony Baker said 1054 days ago:

This bites. While I’ll definitely be updating to Leopard, I’ll have to go off Safari if this happens and chew on Firefox (ack) instead. While I love Firefox on the PC, I just haven’t been a fan on the Mac.

Safari without Inquisitor? NOOOOOO! Jesus.

And who’s ever had nefarious crap done with InputManagers in their browser? I’ve never heard of such a thing…

No.9

∞ Chris Fonnesbeck said 1054 days ago:

This would mean a permanent move to OmniWeb for me. Inquisitor and PicLens are what keep me on Safari. Lack of plugins are fine if there are a decent number of features included (which counts against Safari and Camino). The last thing you want are dozens of add-ons whoring up your browser, but a reasonable baseline number of features is a must. Safari 3 should focus less on things like Dashboard widget-making and more on things like type-ahead find and decent search bar.

No.10

∞ Tom said 1054 days ago:

“I have seen the end. No one was spared, not even the plugins.”

So they put lax controls on AppleTV effectively allowing users to easily circumvent the iTunes-playable-formats-only functionality, but they RESTRICT the few things that actually are beneficial to Safari users…

Why? Starts with “D” and ends with “ollar”. There’s no money in Safari, and they know Firefox has all the extensibility anyway. It’s just sad they gave up on being the on the good guys’ side in the browser realm.

No.11

∞ Kuswanto said 1053 days ago:

Not a good news :(

No.12

∞ Adam Schilling said 1053 days ago:

Hopefully the ‘bright side’ reveals a brand new version of Safari—think iPhone demo, but better—and blows us all away (of course, a proper plugin API would be nice, too).

Failing that, I’m happy to stick with OmniWeb (even if it has been crashing every now and again … culprit = ‘Java’, ... I think).

No.13

∞ Stuart Morgan said 1053 days ago:

“It was news to me, but apparently InputManagers are a security risk.”

Sure; as a simple example, it would be easy to write an InputManager that would load into any browser, read any saved username+password information from the Keychain that was saved from that browser, and send it all off to some some nefarious site, completely circumventing the security model of the Keychain.

No.14

∞ Jonathan said 1052 days ago:

Input Managers as a security risk:

http://projects.info-pull.com/moab/MOAB-22-01-2007.html

http://xforce.iss.net/xforce/xfdb/31676

and most famously, the Oompa Loompa/Leap.A trojan exploited the security hole that is InputManagers:

http://www.rixstep.com/1/20060216,00.shtml

From http://www.sophos.com/virusinfo/analyses/osxleapa.html:

OSX/Leap-A is an instant-messaging worm for the Mac OS X platform.

The worm attempts to spread via the iChat instant messaging system, sending itself to available contacts on the infected users’ buddy list in a file called latestpics.tgz. This file is an archive consisting of:

latestpics: the worm executable
._latestpics: a hidden resource file designed to disguise the executable as a JPEG image

OSX/Leap-A installs itself as an application hook by deleting the “apphook” subdirectory of either the /Library/InputManagers/ directory (if run with root permissions) or the ~/Library/InputManagers/ directory (if run as a non-root user) and replacing it with the following three files:

apphook/Info
apphook/apphook.bundle/Contents/Info.plist
apphook/apphook.bundle/Contents/MacOS/apphook

OSX/Leap-A attempts to infect recently used applications by overwriting the original application with a copy of the worm, storing the original application in the file’s resource fork. Infected application files have the following extended attribute:

name: oompa
value: loompa

OSX/Leap-A also creates the following temporary files:

/tmp/pic.gz
/tmp/pic
/tmp/latestpics
/tmp/lastespics.tar
/tmp/lastespics.tar.gz
/tmp/lastespics.tgz

and several files under

/tmp/apphook

No.15

∞ Massimo said 1051 days ago:

I also do pray for an alternative. Without Saft / Inquisitor, I would switch to Firefox immediately…

No.16

∞ ecco said 1051 days ago:

input managers are a security risk? of course! every extension and every third party application is a security risk.
do you really trust camino or adium? inquisitor or vienna? smultron or neo office?
really?

No.17

∞ Ian Adams said 1051 days ago:

I can’t say I’ll really miss Saft or Stand or anything like that (it’s been awhile since I’ve used either of them) but I would definitely miss PIthHelmet. In fact, you could get rid of every other plugin out there, and I’d just get used to it. PithHelmet, on the other hand, would be a major loss.

No.18

∞ Joshua said 1050 days ago:

If it stays as such, and there is no alternative presented, that is a sad day indeed. I find using a stock installation of OS X useable, and certainly more pleasant than Windows… but it’s all the 3rd party plugins I rely on that really push the whole OS over the top and make it fantastic.

I wonder then about APE, will everyone begin to use it as well? I know Apple hates APE and has even said before that their bug reports automatically toss any reports that have APE code in them.

No.19

∞ Peter da Silva said 1049 days ago:

Input managers are NOT a security risk.

It is not technically possible to prevent a program that has penetrated your computer from hiding itself in your system and restarting itself on demand, except by preventing you, yourself, from running applications you write or download. It is also not possible to prevent a program from modifying the environment of newly-run applications except by preventing you from doing so, which again comes down to preventing you from installing and running software.

Security is like sex. Once you’re penetrated you’re f***ed. The front lines of your system are the applications that sit between the local environment and the outside world, and while Apple does a better job than Microsoft here they’re so far from following good security guidelines that they have NO leg to stand on if they’re castigating Unsanity or anyone else for providing useful tools.

Apple: I call on you, remove “Open safe files after downloading” and stop Safari from using launchservices to find helper applications… THEN you can start worying about third parties.

No.20

∞ Peter da Silva said 1049 days ago:

As far as the MOAB post is concerned, this is a standard issue with any privileged process. A privileged program MUST run with an environment that has been sanitised, or it must sanitise any element of its environment before using it.

This means:

1. Use a standard search path for programs it runs, run the programs explicitly, or ensure that there are no user-writable components in the file system from the root to any directory in the search path.

2. Use a standard search path for shared libraries, or load shared libraries explicitly.

3. Do not run any per-user configuration code (for example, running applications using the user’s shell, or using a shell that loads per-user configuration tools).

Setuid applications are special. If the use of a feature by a setuid application can lead to a security break, you modify the feature so that it doesn’t work in setuid applications. If you removed every feature that shouldn’t be used by setuid applications, you wouldn’t have much of an OS left.

PS: the MOAB issue is #3.