A deprecated Apple authorization API, invoked by third-party installers, is still developers’ preferred choice for updating apps and services on macOS. And that’s a problem because of a massive security issue that could be abused by a local attacker to elevate privileges to root with a little unwitting help from the user.
The situation is known and was raised again last month during DEF CON by noted Mac security researcher Patrick Wardle, chief security researcher at Synack. What compounds the potential severity associated with the continued use of the AuthorizationExecuteWithPrivileges API is that installers for popular applications such as Slack, Google Chrome, Google-owned Dropcam, VMware Fusion, numerous security software updaters, and the open source update library Sparkle all call the deprecated API during updates.
The API, Wardle explained, causes the system to display the familiar authentication dialog box, which is handled by a separate daemon, meaning the user doesn’t have to entrust the application installer with their password. The operating system instead passes trust, and any functionality needing admin or root privileges upon installation may proceed as such.
AuthorizationExecuteWithPrivileges, however, doesn’t validate what is about to execute on the machine wasn’t maliciously modified, Wardle said. Therefore, an attacker already present on the computer and running their code, can wait for the third-party installer to call the insecure authorization API and piggyback off the user’s credentials as they’re entered into the dialog box.
“Normally what happens is these applications ask the operating system to execute something as root, and what they ask to execute is writeable by everyone, something that’s in Temp or the downloaded application bundle,” Wardle said. “Local code, malware or a local attacker who already has access to the box can basically modify what’s about to be executed as root. Since the system doesn’t verify what the application requested to be executed wasn’t modified, when the user puts in their credential and clicks install, the system will execute whatever was requested even if that has been maliciously modified.”
Wardle said the situation extends to Apple’s own installer as well, which suffers from a separate, but related issue. He explained that as a user double-clicks on a .pkg file, Apple’s installer.app executes and looks for plugins in the file and copies them to Temp, loading those libraries into the process context of the installer application, which is signed by Apple and trusted by the OS. Wardle said that a local attacker can win a race condition and modify those packages before they’re installed on the local system. The malicious—and unsigned—dylibs, since they’re not verified by the installer app, will be blindly loaded, Wardle said. Those malicious dylibs can create their own easily forged authentication popup that will be trusted by the OS. The user will then enter their credentials, unwittingly giving malicious code permission to run as root on the machine.
Apple deprecated the AuthorizationExecuteWithPrivileges API in 2013 and now recommends developers use another called SMJobBless.
SMJobBless works by copying whatever its being asked to install into a higher privileged directory, and once it’s in that secure directory, SMJobBless cryptographically validates that it hasn’t been tampered with and then asks the user to authenticate.
Developers, however, are running headlong into a much more complicated scenario when they choose to rely on SMJobBless instead, starting with the fact that it requires developers by an Apple developer certificate to perform the required cryptographic signing.
“The problem is that there is a secure solution, but it costs money and it’s incredibly complicated. It took me several hours to get it working,” Wardle said. “Whereas the deprecated API is literally like three lines of code. It’s really easy and that’s why everybody uses it.”
Wardle said he privately disclosed to Apple that its installer was loading unsigned libraries; Apple has yet to respond, Wardle said. He also said he reported the API issue to Google with regard to Chrome and it responded that it was aware, and that no “good replacement exists”—including SMJobBless.
“Looking at the secure replacement, it’s such a pain to get working,” Wardle said. “There’s a massive tradeoff. In an ideal world, everyone would use the secure replacement or Apple would provide a secure replacement that would be easier to use. When you have the Chromium guys saying this isn’t a valid replacement, they generally know what they’re talking about.”
