CVE-2018–8412: MS Office 2016 for Mac Privilege Escalation via a Legacy Package

The patch has been released, please upgrade your MAU to 18081201

Microsoft Autoupdate Helper 3.18(180410) + legacy SilverLight insecure installer package EoP

This issue affects Microsoft Office for Mac 2016, and SkypeForBusiness (

This report covers two main flaws:

  • code signature validation bypass
  • insecure installer module loading

XPC validation bypass

In /Library/PrivilegedHelperTools/ there's a XPC service

It’s based on NSXPCConnection and only exports two methods:

@protocol MAUHelperToolProtocol
- (void)logString:(NSString *)arg1 atLevel:(int)arg2 fromAppName:(NSString *)arg3;
- (void)installUpdateWithPackage:(NSString *)arg1 withXMLPath:(NSString *)arg2 withReply:(void (^)(NSString *))arg3;

Only whitelisted valid Microsoft signed binaries are allowed:

char __cdecl -[MAUHelperTool listener:shouldAcceptNewConnection:](MAUHelperTool *self, SEL a2, id a3, id a4)

caller_pid = (unsigned __int64)objc_msgSend(v6, "processIdentifier", self);
ksecguestattrpid = kSecGuestAttributePid;
number_with_pid = objc_msgSend(&OBJC_CLASS___NSNumber, "numberWithInt:", caller_pid);
pid_as_nsnumber = objc_retainAutoreleasedReturnValue(number_with_pid);
_dict = objc_msgSend(
attributes = objc_retainAutoreleasedReturnValue(_dict);
guest_code = 0LL;
v12 = 0;
if ( !(unsigned int)SecCodeCopyGuestWithAttributes(0LL, attributes, 0LL, &guest_code) )// kSecCSDefaultFlags
v43 = 0LL;
v12 = 0;
if ( !(unsigned int)SecRequirementCreateWithString(
CFSTR("(identifier \"\" or identifier \"\") and anchor apple generic and certificate 1[field.1.2.840.113635.] and certificate leaf[field.1.2.840.113635.] and certificate leaf[subject.OU] = UBF8T346G9"),
&v43) )
v12 = (unsigned int)SecCodeCheckValidity(guest_code, 0LL, v43) == 0;
if ( v43 )

Here are two (potential) ways to bypass.

First, it uses pid, which can not be trusted since exec* functions can replace the process itself to another, leaving the previous pid untouched. See MacOS/iOS userspace entitlement checking is racy and Don’t Trust the PID!

Actually this way is unexploitable. The invalidation handler is called when the caller tries to replace itself, which cause the [MAUHelperTool shouldExit] method returns true.

v30 = _NSConcreteStackBlock;
v31 = -1040187392;
v32 = 0;
v33 = sub_100002748;
v34 = &unk_100008440;
v19 = (void *)objc_retain(v27, v7);
v35 = v19;
objc_copyWeak(&v36, &v43);
objc_msgSend(v7, "setInvalidationHandler:", &v30);
v20 = objc_msgSend(v19, "loggingConnections");
v21 = (void *)objc_retainAutoreleasedReturnValue(v20);
objc_msgSend(v21, "performSelectorOnMainThread:withObject:waitUntilDone:", "addObject:", v7, 1LL);
__int64 __fastcall sub_100002748(__int64 a1)
void *v1; // rax
void *v2; // r14
__int64 v3; // rbx
  v1 = objc_msgSend(*(void **)(a1 + 32), "loggingConnections");
v2 = (void *)objc_retainAutoreleasedReturnValue(v1);
v3 = objc_loadWeakRetained(a1 + 40);
objc_msgSend(v2, "performSelectorOnMainThread:withObject:waitUntilDone:", "removeObject:", v3, 1LL);
return objc_release(v2);

Then the main event loop will terminate the process. So this won’t work.

But another way is to spawn a valid process with DYLD_* env that enables dynamic code injection.

Since following files are not protected, they can be abuse to bypass the signature check.

  • /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate
  • /Library/Application Support/Microsoft/MAU2.0/Microsoft AU AU Daemon

To protect these binaries, use any one of the following:

  • Library Validation, add -o library to "Other Code Signing Flags"
  • MachO file has a section named __RESTRICT or __restrict
  • MachO file is signed with entitlements

So now I have the ability to talk to the XPC.

Messing up with the log looks useless. Inside -[MAUHelperTool installUpdateWithPackage:withXMLPath:withReply:], it accepts a path from XPC client and install it. But it locks the package file and also perform digital signature validation on the package!

Insecure module loading in legacy SilverLight package

I was unable to bypass the signature validation on pkg file and this issue seems unexploitable.

I made a decision: not to bypass.

After inspecting some valid packages, I found the legacy SilverLight installer:

Trusted of course:

$ pkgutil --check-sign /Volumes/Silverlight/silverlight.pkg
Package "silverlight.pkg":
Status: signed by a certificate trusted by Mac OS X
Certificate Chain:
1. Developer ID Installer: Microsoft Corporation (UBF8T346G9)
SHA1 fingerprint: 9B 6B 91 3B B1 3F 68 26 12 20 EC 72 11 F0 F2 0E 92 E4 B1 EB
2. Developer ID Certification Authority
SHA1 fingerprint: 3B 16 6C 3B 7D C4 B7 51 C9 FE 2A FA B9 13 56 41 E3 88 E1 86
3. Apple Root CA
SHA1 fingerprint: 61 1E 5B 66 2C 59 3A 08 FF 58 D1 4A E2 24 52 D1 98 DF 6C 60

The post-install script caught my attention.

Set global write permission:

pushd /Library/Internet\ Plug-Ins/
rm -rf WPFe.plugin/
chown -R root:admin Silverlight.plugin/
chmod -R 775 Silverlight.plugin/
pushd /Library/Application\ Support/Microsoft/
chown -R root:admin Silverlight/
chmod -R 775 Silverlight/
pushd /Library/Application\ Support/
chown root:admin Microsoft/
chmod 775 Microsoft/

Interesting commands:

_PRIBX=`ls -r "/Library/Application Support/Microsoft/PlayReady/Cache" | grep .key | awk '{if (NR==1) {print $1}}' `
if [ "$_PRIBX" ]
_PRIBXVER=`./PlayReadyGetIBXVersionTool "/Library/Application Support/Microsoft/PlayReady/Cache/"$_PRIBX`
if [ "$_PRIBXVER" = "mspribx.1.5.8" ]
pushd "/tmp/SilverlightInstallTools"
_SPRDResult=`./rundylib "/Library/Internet Plug-Ins/Silverlight.plugin/Contents/MacOS/SLMSPRBootstrap.dylib"`

(it’s writable after previous chmod)

So what do they do?

rundylib, just as its name

int __cdecl main(int argc, const char **argv, const char **envp)
v3 = argv[1];
if ( !v3 )
puts("ERROR: Invalid path ");
return 1;
v5 = dlopen(v3, 5);

What about PlayReadyGetIBXVersionTool?

signed int __cdecl GetDyLibVersion(const char *path, unsigned int *a2, unsigned int *a3, unsigned int *a4)
handle = dlopen(path, 1);
if ( handle )
v6 = _dyld_image_count();
for ( i = 0; ; ++i )
if ( i == v6 )
goto LABEL_22;
v8 = _dyld_get_image_name(i);
if ( !v8 )
v9 = dlerror();
printf("Image name not found or index out of range. Error: %s\n", v9);
v5 = 5;
goto LABEL_21;
if ( !strcmp(v8, path) )
v10 = _dyld_get_image_header(i);
if ( !v10 )

It just loads and executes an shared library, from the “Cache”, in a privileged process, just to get its version.

Both /Library/Internet Plug-Ins/Silverlight.plugin/Contents/MacOS/SLMSPRBootstrap.dylib and /Library/Application Support/Microsoft/PlayReady/Cache are writable by non-privileged user. But the former needs to win the race. I prefer stabler exploit.

The exploit

So the exploit is deadly simple.

  1. DYLD_INSERT_LIBRARIES to inject "Microsoft AutoUpdate"
  2. Place the vulnerable SilverLight installer somewhere, send XPC to updaterhelper to ask for installation
  3. Create cache folder and place the shared library for root context
  4. The installer gets executed and our evil code was loaded by a rooted process