Input Managers in 10.5

[hotdamn]

Ok so while the 13 year olds are smashing their heads in because they don't like the new dock, is there anyone who can confirm or deny that the GM build of Leopard has the activation dialogue for the Input Managers still in it (and if yes, how to get there. miss my inquisitor ).

Thanks.

 

[richard.mac]

just upgraded to leopard and saft and inquisitor do not work! ive still got an input managers folder in my user library but safari just completely ignores them. hopefully developers of input managers will provide a workaround in a couple of weeks

 

[SC68Cal]

Input managers were a security hole. Good riddance.

 

[stomer]

Input managers were a security hole. Good riddance.

So how am I supposed to block adverts in Safari now? There must be a way. Otherwise I think I'll end up going back to Camino.

 

[thefunkymunky]

And what about being able to save browser sessions. I like the way Saft done this. Is there an extension like this that works with Leopard.

[EDIT] I found this for session saving. Safari has it built-in...kinda.

 

[richard.mac]

So how am I supposed to block adverts in Safari now? There must be a way. Otherwise I think I'll end up going back to Camino.

search for a style sheet called "GoodVibrations.css" and chuck it in the advanced section in safari preferences. blocks ads very well!

 

[stomer]

search for a style sheet called "GoodVibrations.css" and chuck it in the advanced section in safari preferences. blocks ads very well!

That works great. Thanks.

 

[Veri]

Input managers were a security hole. Good riddance.

This is a common misconception. An InputManager plugin, put vaguely, provides a convenient interface for programmers to override certain functionalities of a Cocoa applications. But installing an InputManager requires the privileges of the currently executing user (or an administrator), and since that user already has the ability to arbitrarily modify his files or running processes, there is nothing a program can do using InputManagers that it couldn't also do by other means. For example, APE uses (iirc) mach_override and mach_inject to modify the code of running processes - this is more general than InputManagers and does not require Cocoa.

It is possible to argue that InputManagers provide a convenient interface for a malicious programmer - but it's also "convenient" that OS X allows programmers to easily write/modify files on disk, and that's an essential component of any malware. No-one is asking for OS X to stop providing file handling functions, however.

A couple of implementation notes:

• It is necessary for the OS to make sure that an app running with high privileges doesn't load an InputManager provided by a regular user. But this is no different from the custom list of libraries to preload (LD_PRELOAD) being ignored when you're running software that's designed to run as administrator (suid root).
• A UI for selecting which InputManagers are enabled for which apps would be nice, but I believe there are third party programs to facilitate this. But you are already in trouble if you're running malicious code with your privileges, regardless of the app - OS X, like most traditional Unixes, has fairly coarse access control. Perhaps Leopard sandboxes will help with running "semi-trusted" software, but I haven't read about them yet.

 

[SC68Cal]

For example, APE uses (iirc) mach_override and mach_inject to modify the code of running processes - this is more general than InputManagers and does not require Cocoa.

Oh this is funny. You're bringing up APE? That ***** is even more dangerous.

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

 

[thejadedmonkey]

Oh this is funny. You're bringing up APE? That ***** is even more dangerous.

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

That looks way nasty! Has it been fixed?

 

[SC68Cal]

That looks way nasty! Has it been fixed?

I'd certainly hope, but the thing is that it's just lipstick on the pig. Yeah, they might have fixed this issue, but the bigger question of "Should we allow 3rd party developers that create an application that can do mach-inject code on our system?" just so you can have junk like "Window Shade" and all kinds of other BS?

 

[dmelgar]

Argh. This is horrible. I heavily relied upon SafariBlock to block ads, and 1passwd to handle complex password scenarios. Both of these critical extensions no longer work with Safari.

I am forced to use Firefox even though I've grown to like Safari much better.

This alone is a reason I wish I could downgrade back to Tiger.

 

[Veri]

Oh this is funny. You're bringing up APE? That ***** is even more dangerous.

From the page:

This binary is executed with root privileges and drops them (via setuid to current user id), but the file is actually writable, as well as the whole tree under /Library/Frameworks, allowing the mentioned condition to be abused for privilege escalation.

This has nothing whatsoever to do with whether mach_override, mach_inject or InputManager plugins are dangerous. The complaint, assuming it's accurate, appears to be that unprivileged users (well, members of the admin group, afaict) can modify components of APE that are loaded while it's running as root.

The OS "flaw" here is the ability to run executables with higher privileges than the currently executing user; if the solution to poor deployment is to remove an OS facility, then one should argue for the removal of suid capability from the OS :/.

Of course, the actual flaw is in APE loading code that can be modified by a less-privileged user into a more-privileged context. It should store its code somewhere only writeable by root, or somehow check binary integrity (e.g. file ownership - but beware race condition vulnerability).

This episode reminds me of Steve Gibson claiming that raw socket capability in Windows XP was a vulnerability.

 

[SC68Cal]

The OS "flaw" here is the ability to run executables with higher privileges than the currently executing user; if the solution to poor deployment is to remove an OS facility, then one should argue for the removal of suid capability from the OS :/.

Just a suggestion. Don't read things while you're cross-eyed.

The advisory is that Application Enhancer can be backdoor'd and patched so that it runs as root, rather than in the context of the user executing it, because of insecure file permissions.

 

[thestaton]

Argh. This is horrible. I heavily relied upon SafariBlock to block ads, and 1passwd to handle complex password scenarios. Both of these critical extensions no longer work with Safari.

I am forced to use Firefox even though I've grown to like Safari much better.

This alone is a reason I wish I could downgrade back to Tiger.

1passwd works great, you just gotta upgrade your version.

 

[Veri]

The advisory is that Application Enhancer can be backdoor'd and patched so that it runs as root, rather than in the context of the user executing it, because of insecure file permissions.

The ApplicationEnhancer framework already runs as root. The vulnerability is demonstrated by showing that it can be patched so that it never gives up root privileges before executing aped. It can be patched because of the file permissions problem I explained in the first paragraph. The solution I explained in my third paragraph.

The second paragraph was an attempt at proof by contradiction - assume, as in your original post, that an exploit created by poor development practice is to be blamed on an OS flaw (hence "flaw" in quotes). One then concludes that the ability to run privileged software while logged in as another user is the flaw in question. The solution must then be to remove essential functionality which enables this, such as suid. Since such a solution is nonsense, we conclude that in fact we should not be looking for an OS flaw to fix, but to fix APE.