{"id":40401,"date":"2023-08-21T14:31:41","date_gmt":"2023-08-21T18:31:41","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=40401"},"modified":"2023-08-21T14:31:41","modified_gmt":"2023-08-21T18:31:41","slug":"bypassing-app-management-with-textedit","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2023\/08\/21\/bypassing-app-management-with-textedit\/","title":{"rendered":"Bypassing App Management With TextEdit"},"content":{"rendered":"

Jeff Johnson<\/a> (Mastodon<\/a>):<\/p>\n

In retrospect, I regret participating in the Apple Security Bounty program. It has been a giant, frustrating waste of time, and I wish I had just dropped this 0day on October 24 of last year when Ventura was released. I suspect that if I had done so, Apple would have found a way to address the issue already in Ventura. Thus, I feel that my prolonged silence has not protected Mac users. The standard practice in reporting a security vulnerability is to give the vendor 90 days to address the issue, and I’ve given Apple vastly more time than expected.<\/p>

[…]<\/p>

I discovered—almost by accident—that a sandboxed app could modify files that it shouldn’t be able to modify: files inside the bundle of a notarized app that were supposedly protected by App Management security.<\/p>

[…]<\/p>

This isn’t the first time that a major macOS update included a new security (theater) feature with a gaping hole. For example, I previously discovered a bypass for Mojave’s new privacy protections<\/a>. And it’s important to keep in mind that I’m not a professional security researcher.<\/p><\/blockquote>\n\n

It’s hard to make a living reporting security bugs when Apple has a history of declaring them not bugs, being stingy with payments, and stalling<\/a>—which encourages releases like this that forfeit the possibility of collecting a bounty.<\/p>\n\n

Jeff Johnson<\/a>:<\/p>\n

Today I want to illustrate the vulnerability a little more clearly to a non-developer audience.<\/p>

[…]<\/p>

As you can see, modifying that file would mess with Firefox’s software update mechanism, perhaps leaving the user vulnerable to a malicious software update.<\/p>

[…]<\/p>

TextEdit is sandboxed. Ironically, sandboxing was designed to prevent<\/em> attacks, but in this case it allows<\/em> an attack. That’s the bug, the vulnerability. A sandboxed app can modify a file that is supposed to be protected by App Management.<\/p>

[…]<\/p>

This has all been just for illustration. It wasn’t a real, viable attack, because I had to do everything manually. However, my disclosure yesterday presented an example of an automated tool that could execute a real attack.<\/p><\/blockquote>\n\n

Thijs Alkemade<\/a>:<\/p>\n

When I looked at this feature before Ventura was released I immediately found 4 different ways to bypass it. It really looks like it hasn’t been tested at all, as every potential method I’ve thought of worked. But bypassing by using a sandboxed app was not something I could have imagined working. 😂<\/p><\/blockquote>\n\n

Previously:<\/p>\n