An explanation of why "createmobileaccount" breaks in OS X 10.10.3 (and why a particular workaround works)

00_explanation.md

10.10.3: createmobileaccount

Today, @osxreverser on Twitter announced their analysis of Apple's OS X 10.10.3 fix for CVE-2015-113 privilege escalation (aka "rootpipe") and an adapted unofficial fix for OS X 10.9:

https://twitter.com/osxreverser/status/587639173919727616

Apple apparently added a new private entitlement named "com.apple.private.admin.writeconfig" and made it required for calling the XPC service "writeconfig".

Shortly after 10.10.3 was released, it was discovered that the tool "createmobileaccount" (which can be used to pre-create a mobile account and home path prior to a user with network credentials logging into a machine) was no longer functioning properly.

Greg Neagle (@gregneagle on Twitter) put forward that the change to the writeconfig XPC service was the culprit:

https://twitter.com/gregneagle/status/587649138948341760

Additionally, though, it was noticed that various ways of pre-creating the home folder seemed to get around the issue in some fashion.

Confirmation of the root of the bug

The root cause is a particular method call of a class from the same framework early identified as a mechanism for CVE-2015-113: the PrivateFramework named SystemAdministration.framework.

In the case of createmobileaccount, it utilizes the class "ADMUser" and calls the method "createHomeDirectoryWithParameters:"

Below you can see a snippet of the code in question:

01_disasm.m

char -[ADMUser createHomeDirectoryWithParameters:](void * self, void * _cmd, void * arg2) {
    var_B0 = arg2;
    r12 = self;
    rbx = *objc_msgSend;
    rax = [WriteConfigClient sharedClient];
    rax = [rax isAuthenticated];
    LOBYTE(rbx) = 0x0;
    if (LOBYTE(rax) != 0x0) {
            r14 = [r12 homeDirectory];
            var_50 = 0x0;
            var_48 = var_50;
            var_40 = 0x0;
            rax = *kCFPreferencesAnyApplication;
            var_3C = 0x20;
            r13 = *rax;
            rax = *kCFPreferencesAnyHost;
            rdx = **kCFPreferencesCurrentUser;
            rcx = *rax;
            var_38 = 0x1;
            r15 = CFPreferencesCopyValue(@"AppleLanguages", r13, rdx, rcx);
            if (r15 != 0x0) {
                    CFMakeCollectable(r15);
            }
            if ([var_B0 objectForKey:@"path"] != 0x0) {
                    r14 = [var_B0 objectForKey:@"path"];
            }
            rax = [NSFileManager defaultManager];
            rax = [rax fileExistsAtPath:r14 isDirectory:var_29];
            if (LOBYTE(rax) != 0x0) {
                    LOBYTE(rbx) = 0x0;
                    NSLog(@"Directory at path:%@ already exists", r14);
                    [r15 release];
            }
            else {
                    [[[WriteConfigClient sharedClient] remoteProxy] createPath:[[r14 stringByDeletingLastPathComponent] stringByResolvingSymlinksInPath] attributes:0x0];
// [...]

02_part2.md

If you look at line 5, you can see where it sets up to create a connection to the XPC service at the heart of the vulnerability:

rax = [WriteConfigClient sharedClient];

Avoiding the bug

But if you'll notice lower down at line 28, "createHomeDirectoryWithParameters:" checks to see if the directory already exists:

rax = [rax fileExistsAtPath:r14 isDirectory:var_29];

If it exists, the entire code block which calls the XPC service is missed due to it being on the other half of the "if else" block.

There are some writeups about avoiding the bug by pre-creating the directory and populating it with the contents of the user template folder, but given the complexity of properly intializing a user profile, I'd consider this a temporary fix at best right now. Having the user directly log into the machine will trigger normal home directory creation.

If anything, point your Apple support contacts to this information / make sure to report this bug. It's an easy fix for Apple - they just need to add the "com.apple.private.admin.writeconfig" entitlement to the createmobileaccount binary and re-sign it.

excellent, thanks for the information!
What tool did you use to disassemble createmobileaccount ?