Bypassing Mojave Security Protections
Researcher Patrick Wardle, who has uncovered many security flaws in Apple’s macOS operating system, today shared some details on a new vulnerability that he’s found in the newly released macOS Mojave update.
As outlined by BleepingComputer, Wardle discovered that he was able to access Contacts data from the address book using an unprivileged app, as demonstrated in the video below.
And a separate vulnerability from Sentinel One:
Here, we have remotely logged in to Sally’s user account via
sshand retrieved the last website she visited, a banking logon page, by reading the LastSession.plist stored in the (supposedly) protected Safari folder.Importantly, the ability to
sshinto the local account and traverse the protected folders does not require pre-approval of Terminal in Full Disk Access, and can even be performed locally by Sally herself withssh[…] In short, any local or remote user can bypass the Full Disk Access requirement simply by logging in viassh.
This is pretty demoralizing. I’ve spent months trying to make smooth user experiences in spite of the hurdles Apple has added for developers (in some cases without even telling them). Some things are broken and not in my control to fix. Even once things settle down, my customers will still have to jump through extra hoops to use my apps. And yet the bad guys can still get at the protected data, anyway.
Presumably these will be fixed, and maybe Apple will eventually improve the user interface, but it just seems like this shipped far before it was ready. As did the rest of Mojave, as there wasn’t even time to distribute a GM build.
Previously: Mojave’s New Security and Privacy Protections Face Usability Challenges.
Update (2018-09-25): Jeff Johnson:
I’ve got 1 too, different from the other 2
Update (2018-09-26): Dave Nanian:
The nice thing about the Vista-ing of Mojave is that it’s a huge pain for everyone but the people who you have to worry about.
Update (2018-09-27): Jeff Johnson:
I used a different attack vector than SentinelOne (ssh) and Wardle. I don’t know what Patrick’s attack vector is, but I did ask him if he used mine, and he said no. So there are at least 3 different privacy protection bypasses in Mojave. I suspect that there are even more.
Update (2018-11-06): Jeff Johnson:
As of today, the support document does not mention the privacy protection bypass that I discovered and alluded to in my blog post. Nonetheless, macOS 10.14.1 does appear to fix the main issue, although there remain other avenues for bypassing Mojave’s privacy protections under certain conditions.
[…]
The privacy protection bypass that I discovered is quite simple. It’s obvious that Apple exempted some of its own code from Mojave’s privacy protections; for example, you’re able to navigate protected folders in Finder without triggering permission dialogs.[…] The body in this case was Automator. Or more accurately,
/usr/bin/automator.[…]
Another possible way to bypass Mojave privacy protections is to “piggyback” on another app. Even if a malicious app is unable to obtain special permission itself, the app can use another app that has already been granted permission, such as Terminal app.
10 Comments RSS · Twitter
I think better security is always the goal but I can't help but think security is a smokescreen for Apple preempting more control from users and developers. It just seemed more walled garden focused than anything.
The local user having access to their own data is _not_ a vulnerability. Connecting via SSH as that user is by definition the same thing, and has all rights the user has. The second "vulnerability" shows a fundamental lack of understanding of SSH.
@Josh The point is that the system was clearly designed so that the local user does not have access to their own data. I agree that connecting via SSH should be the “same thing,” which is why it doesn’t make sense that you have more rights logging in remotely than you do locally.
It looks like as if Team A- is in charge of security and Team C is in charge of Security UI/UX.
"and maybe Apple will eventually improve the user interface"
Don't hold your breath. Secure Kernel Extension Loading UI/UX in Mojave is still as shitty as it was in High Sierra.
@Michael: Let's just say it took them 1 year to implement what they could have done in 1 hour (5 minutes of code, the other 55 minutes to add the localizations) after the first beta of High Sierra was provided.
And in 1 year, they haven't been able to figure out that it should be possible to allow the extensions from this very same dialog.
And apparently, the CPUs of the Mac are still not enough powerful to figure out whether we're talking about one or more extensions.
I really wonder about this. How many examples will there be of this actually protecting somebody, compared to the examples of this preventing people from doing things they should be able to do? Security is often a tradeoff, but we tend to not spend any time thinking about what the tradeoff actually is. Instead, we just assume that more security is always worth the cost.
@Lukas Yep. I’m currently dealing with customers who, after going through all the steps to give my apps access in Mojave, then have to do it repeatedly because something is messed up in the TCC database and it forgets they’ve already given access.
[…] have supposedly been locked down, but various bypasses have already been revealed (see here and here, for example) and they are largely null and void in any case as soon as a user adds the Terminal to […]
