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.”