Input Managers in 10.5

Discussion in 'macOS' started by hotdamn, Oct 25, 2007.

  1. hotdamn macrumors 6502

    Joined:
    Jan 24, 2007
    Location:
    Ottawa, ON, Canada
    #1
    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.
     
  2. richard.mac macrumors 603

    richard.mac

    Joined:
    Feb 2, 2007
    Location:
    51.50024, -0.12662
    #2
    just upgraded to leopard and saft and inquisitor do not work! :mad: 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
     
  3. SC68Cal macrumors 68000

    Joined:
    Feb 23, 2006
    #3
    Input managers were a security hole. Good riddance.
     
  4. stomer macrumors 6502a

    Joined:
    Apr 2, 2007
    Location:
    Leeds, UK
    #4
    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.
     
  5. thefunkymunky macrumors 65816

    Joined:
    Feb 24, 2005
    Location:
    London
    #5
    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.
     
  6. richard.mac macrumors 603

    richard.mac

    Joined:
    Feb 2, 2007
    Location:
    51.50024, -0.12662
    #6
    search for a style sheet called "GoodVibrations.css" and chuck it in the advanced section in safari preferences. blocks ads very well!
     
  7. stomer macrumors 6502a

    Joined:
    Apr 2, 2007
    Location:
    Leeds, UK
    #7
    That works great. Thanks.
     
  8. Veri macrumors 6502a

    Joined:
    Sep 23, 2007
    #8
    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.
     
  9. SC68Cal macrumors 68000

    Joined:
    Feb 23, 2006
    #9

    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
     
  10. thejadedmonkey macrumors 604

    thejadedmonkey

    Joined:
    May 28, 2005
    Location:
    Pa
    #10
  11. SC68Cal macrumors 68000

    Joined:
    Feb 23, 2006
    #11
    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?
     
  12. dmelgar macrumors 68000

    Joined:
    Apr 29, 2005
    #12
    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.
     
  13. Veri macrumors 6502a

    Joined:
    Sep 23, 2007
    #13
    From the page:
    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.
     
  14. SC68Cal macrumors 68000

    Joined:
    Feb 23, 2006
    #14
    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.
     
  15. thestaton macrumors 6502

    Joined:
    Jan 19, 2006
    #15
    1passwd works great, you just gotta upgrade your version.
     
  16. Veri macrumors 6502a

    Joined:
    Sep 23, 2007
    #16
    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.
     

Share This Page