{"id":51967,"date":"2026-05-20T14:14:10","date_gmt":"2026-05-20T18:14:10","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=51967"},"modified":"2026-05-20T14:14:38","modified_gmt":"2026-05-20T18:14:38","slug":"hijacking-apps-using-archive-utility","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2026\/05\/20\/hijacking-apps-using-archive-utility\/","title":{"rendered":"Hijacking Apps Using Archive Utility"},"content":{"rendered":"

Talal Haj Bakry and Tommy Mysk<\/a> (Mastodon<\/a>):<\/p>\n

\n

Until macOS 26.4, Archive Utility had nearly unrestricted filesystem access. Combined with a drag-and-drop sandbox quirk, this let an attacker bypass App Sandbox data containers, Transparency, Consent, and Control (TCC) protections, and hijack third-party apps — all without special permissions or elevated privileges.<\/p>\n

[…]<\/p>\n

Here’s one interesting aspect of the macOS app sandbox: dragging and dropping a file or folder onto an application grants it unrestricted access to the dropped item. This is by design. Without it, apps couldn’t access files dragged from protected locations like ~\/Desktop<\/code> or ~\/Documents<\/code>, and drag and drop wouldn’t work in sandboxed apps at all.<\/p>\n

[…]<\/p>\n

Knowing about the drag-and-drop loophole, an attacker can try to convince a user to drag and drop Archive Utility’s preferences file into Terminal, which lets them rewrite Archive Utility’s output folder. From there, copying a file out of an app data container is a two-step move: compress the target file inside a protected area, then extract the archive into a folder the attacker controls.<\/p>\n

[…]<\/p>\n

Code signing should have prevented this kind of tampering with the application bundle, but for some reason macOS didn’t complain. We would like to investigate this further.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n