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

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

This issue affects Microsoft Office for Mac 2016 and SkypeForBusiness (16.17.0.65)

This report covers two main flaws:

  • Code signature validation bypass
  • Insecure installer module loading

XPC Validation Bypass

In /Library/PrivilegedHelperTools/com.microsoft.autoupdate.helper there's a XPC service com.microsoft.autoupdate.helper.

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

Only Microsoft-signed binaries are allowed:

Here are two (potential) ways to bypass.

First, it uses pid, which can not be trusted since exec* family functions can replace current process to a new one, 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 triggered when the caller tries to replace itself, which cause the -[MAUHelperTool shouldExit] method to return true.

Then the main event loop will terminate the process.

But another way is to spawn a valid process with DYLD_* environment vars that enable dynamic code injection.

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

  • /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/Microsoft AutoUpdate
  • /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/Microsoft AU Daemon.app/Contents/MacOS/Microsoft 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 (deprecated)
  • MachO file is signed with entitlements

So now I have the ability to talk to the XPC service. Messing up with the log looks useless. Inside -[MAUHelperTool installUpdateWithPackage:withXMLPath:withReply:], it accepts a path from XPC client and install it. But the daemon locks the package file and also performs digital signature validation on it!

Insecure Module Loading in A Legacy SilverLight Package

I was unable to bypass the signature validation on pkg file and this issue seemed unexploitable. I made a decision: not to bypass it.

After inspecting some valid packages, I found this legacy SilverLight installer: https://www.microsoft.com/getsilverlight/Get-Started/Install/Default

It's trusted of course:

The post-install scripts caught my attention.

Set global write permission:

So what do they do?

rundylib, just as its name

What about PlayReadyGetIBXVersionTool?

It just loads and executes a 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 globally writable. The only difference is that the former needs to win the race. I prefer stabler exploit.

The Exploit

It's deadly simple.

  1. DYLD_INSERT_LIBRARIES to inject to "Microsoft AutoUpdate"
  2. Place the vulnerable SilverLight installer somewhere, send the XPC request to updaterhelper to ask for installation
  3. Create cache folder and place the shared library for root payload
  4. The installer gets executed and our malicious code was loaded as root

Demo: