Thursday, April 16, 2015

systemsetupusthebomb revisited: Vulnerable after all

UPDATE: Edited the below to clarify Takashi's baseline solution.

Previously, previously. tl;dr: Apple uses a setuid binary called writeconfig to alter certain system settings which on at least 10.7+ could be used to write arbitrary files as setuid root, allowing almost instantaneous privilege escalation -- i.e., your computer is now pwned. This was fixed in Yosemite 10.10.3, but not any previous version. Originally I had not been able to exploit my 10.4 systems in the same fashion, so despite the binary being there, I concluded the actual vulnerability did not exist.

Well, Takashi Yoshi has succeeded where I failed (I'm still pretty confident on Darwin Nuke, though), and I have confirmed it on my systems using his RootPipe Tester tool. Please note, before you run, that this tool specifically exploits the vulnerability to write a setuid root file to disk, which if he weren't a nice guy means he now owns your system. Takashi is clearly a good guy but with any such tool you may wish to get in the habit of building from source you've closely examined, which he provides. The systemsetupusthebomb vulnerability is indeed successful on all versions of OS X going back to at least 10.2.8.

Takashi's page also gives a simple workaround: in System Preferences, under Security, check "Require password to unlock each secure system preference" (and make sure the lock at the lower left is locked). Now any known use of the vulnerable tool will either fail or at least prompt you for a password. With this fix in place, the RootPipe Tester cannot function on my 10.4 systems.

If you're more paranoid, however, you can almost completely avoid the risk of an alternative future attack at the price of some system functionality. At its lowest level, the workaround for this vulnerability is straightforward in concept -- disable writeconfig or neuter it -- but has side effects, because if you monkey with writeconfig the system will lose the capability to control certain configuration profiles (in 10.4, this generally affects the Sharing pane in System Preferences; 10.5+, which specifically exposes systemsetup, may be affected in other ways) and may also affect remote administration capabilities. Takashi and I exchanged E-mails on two specific solutions. Both of these possible solutions will alter system functionality, in a hopefully reversible fashion, but a blown command may interfere with administering your computer. Read carefully.

One solution is to rename (or remove, but this is obviously more drastic) writeconfig to something else. Admittedly this works a bit too well. RootPipe Tester actually crashed, which may be useful to completely stop a malicious app in its tracks, but it also made System Preferences unstable and will likely do the same to any app expecting to use Admin.framework. Although 10.4 seemed to handle this a bit better, it too locked up the Sharing pane after banging on it a bit. However, you can be guaranteed nothing will happen in this configuration because it's not possible for it to occur -- apps looking for the victim ToolLiaison class won't be able to find it. Since I'm rarely in that panel, this is the approach I've personally selected for my own systems, but I'm also fully comfortable with the limitations. You can control this with two commands in Terminal on 10.4-10.6 (make sure you fixed the issue with sudo first!):

go to a safe state: cd /System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/ ; sudo mv writeconfig noconfig
go to original state: cd /System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/ ; sudo mv noconfig writeconfig

For added security, make noconfig a custom filename only you know so an attacker won't be easily able to find it in an alternate location ... or, if you're nucking futs, archive or delete it entirely. (Not recommended except for the fascistic maniac.)

Takashi found the second approach to be gentler, but is slightly less secure: strip the setuid bits off. In this mode, the vulnerability can still be exploited to write arbitrary files, but as it lacks the setuid permission it cannot run as root and the file is only written as the current user (so no privilege escalation, just an unexpected file write). Applications that use Admin.framework simply won't work as expected; they shouldn't crash. For example, System Preferences will just "look at you" in the Sharing panel when you try to change or start a new system service -- nothing will happen. For many users, this will be the better option. Here are the Terminal commands for 10.4-10.6:

go to a safe state: cd /System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/ ; sudo chmod u-s writeconfig
go to original state: cd /System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/ ; sudo chmod u+s writeconfig

Choose one of these options. Most of the time, you should leave your system in the safe state. If you need to change Sharing or certain other settings with systemsetup or System Preferences, return to the original state, make the change, and return to the safe state.

Of course, one other option is to simply do nothing. This might be a surprising choice, but Takashi does make the well-taken point that this attack can only be perpetrated upon an administrative user where root is just your password away anyhow, and no implementation of this attack other than his runs on PowerPC. This isn't good enough for me personally, but his argument is reasonable, and if you have to do a lot of configuration changes on your system I certainly understand how inconvenient these approaches could be. (Perhaps someone will figure out a patch for System Preferences that does it for you. I'll leave that exercise to the reader.) As in many such situations, you alone will have to decide how much you're willing to put up with, but it's good to see other people are also working to keep our older Macs better protected on OS X.

Ob10.4Fx IonPower status report: 75% of V8 passing, interrupted briefly tonight to watch the new Star Wars trailer. I have cautious, cautious hope it won't suck, but J. J. Abrams, if you disappoint me, it will be for the last time (to paraphrase).

6 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. Isn't it an option instead of only resetting the setuid bit, resetting all flags? Then it cannot be used to write to any file any more. So chmod 000 to switch off and chmod 4755 to reset the original flags. The only difference is not obscuring the file under a different name. Or am I missing something?
    [sorry, previous comment had errors, typo in flag setting...]

    ReplyDelete
    Replies
    1. Sure, you could do that too. 10.4 probably handles this better than 10.5, but both systems should be protected. There are other ways to skin this cat; we just explored two of them.

      Delete
  3. On RootPipeTester's github page it says 10.4-10.7 aren't vulnerable if we set Security Preferences to require a password to unlock secure system preferences. Does renaming writeconfig give an added benefit?

    Thanks.

    ReplyDelete
    Replies
    1. He must have posted that after he and I discussed. I don't know if there are any benefits, but this seems to cover all the cases I know of for getting the defective tool object, so that may be the better approach as well. It seems to work correctly here, so I'm going to try that. Perhaps Takashi would like to comment.

      Delete
    2. Takashi's reply.

      > The README.md (including the PANIC guides) has been online since the
      > first minute, you can check the commit log for that.
      > I assume we (I and ClassicHasClass) had a misunderstanding. I
      > thought that maybe he didn't trust "Authorization Services" and
      > wanted to go completely paranoid, making sure that it is technically
      > impossible for writeconfig to write such a file.
      >
      > As an answer to Dan's question: I personally couldn't find a way to
      > circumvent "Require Password", but still there might be another
      > vulnerability that is not yet known to me/us. If that's the case,
      > moving away writeconfig will give you the assurance that the
      > ToolLiaison class can't set up a connection which makes _this_
      > exploit impossible - at least for now.
      > I do have an idea how an exploit _might_ be doable even if
      > writeconfig has been tampered with and 10.5 or higher is installed
      > on that system but I don't want to say anything about this until I
      > have tested it.
      >
      > I hope this has clarified the situation a bit. I'll add a TOC to the
      > README so that the PANIC guides can be found more easily.

      Delete

Due to an increased frequency of spam, comments are now subject to moderation.