macOS Gatekeeper bypass lets attackers replace web-downloaded apps, researchers say
Talal Haj Bakry and Tommy Mysk say macOS can trust a swapped app after first launch; Apple reportedly closed the report.
By Dominic Okoye · Staff Writer
· 3 min read
Security researchers Talal Haj Bakry and Tommy Mysk say they found a macOS Gatekeeper bypass that can let an attacker replace the main executable inside a web-downloaded app after the user has opened it once. The claim matters for software teams because many widely used developer and workplace apps, including browsers, chat clients and code editors, are commonly installed outside Apple’s Mac App Store.
Apple says Gatekeeper checks software downloaded from outside the App Store when a user first opens an app, plug-in or installer package. That check is meant to confirm the software comes from an identified developer, has been notarized by Apple as free of known malicious content and has not been changed.
Bakry and Mysk say the protection does not hold in one case they tested. According to the researchers, an attacker with user-level code execution can replace the main executable of an app downloaded from the web without needing administrator privileges. The attack is not remote code execution by itself and is not zero-click: the attacker still needs some way to run code in the user’s account, such as a malicious app, a script or another local execution path.
How does the macOS Gatekeeper bypass work?
The researchers’ scenario starts with an app downloaded from the internet and launched once, allowing Gatekeeper to run its first validation. They say they were then able to archive the app bundle with tar, delete the original and restore a modified version containing a malicious executable. macOS did not ask the user to approve the replacement again, according to the researchers, who also published a demonstration video.
The technique does not apply to Mac App Store apps, the Mysk team told The Register, because those apps are owned by root. A process running with ordinary user privileges would not be able to overwrite them. The potential exposure is instead with apps installed from the web, a category that includes products such as Brave, Slack, Signal and Visual Studio Code.
Mysk said he was not certain what causes the behavior, but suggested it could involve retained trust data after the first successful launch. In his explanation, macOS appears to notice that the app bundle changed and attempts to validate it again, but a previously stored trust decision may allow the modified bundle to pass.
What access would an attacker need?
The researchers listed several possible ways an attacker could get the required user-level execution, including command-line tools, a user being persuaded to paste a command into Terminal, a malicious downloaded app, a prompt injection attack against an AI agent, or a compromised package distributed through npm, Homebrew or another package manager.
Once a replaced app is in place, the researchers warn, it could ask for permissions in a way users are more likely to accept because the prompts appear to come from familiar software. Apple’s Transparency, Consent and Control protections and Keychain access prompts would still require system authorization, according to the researchers’ account of Apple’s position.
Bakry and Mysk reported the issue to Apple, which reportedly closed the case. The researchers said Apple did not treat the proof of concept as a modification of the signed executable, because the archive-and-restore process overwrote the app bundle and made it equivalent to a locally built bundle. Apple did not respond to The Register’s request for comment.
This story draws on original reporting from The Register.
