Image for post
Image for post

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

Aug 22, 2018 · 5 min read

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:

Only whitelisted valid Microsoft signed binaries are allowed:

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.

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:

The post-install script caught my attention.

Set global write permission:

Interesting commands:

(it’s writable after previous chmod)

So what do they do?

rundylib, just as its name

What about PlayReadyGetIBXVersionTool?

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



I write random stuff

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store