Sandbox Doesn’t Protect Files From stat()
Jeff Johnson (tweet, Hacker News):
I discovered that an application can use the venerable Unix command-line tool “ls” (list directory contents) to bypass both TCC (Transparency, Consent, and Control) and the sandbox, enabling unauthorized access to file metadata in directories that are supposed to be protected.
[…]
It’s been almost a year since I reported it to Apple. This is well beyond the bounds of “responsible disclosure”, which is typically 90 days after reporting an issue to a vendor. I’ve never been paid a penny by the Apple Security Bounty Program and doubt I ever will.
[…]
I chose the example of
~/Library/Safari/LocalStoragebecause Safari names the files in this directory according to the web sites that you visit! Also note that the output of long formatls -lcontains the last modification date of the files. Thus, one possible privacy violation from this technique is to learn the user’s web browsing history.
I sort of discovered this issue by accident a few years ago while tracking down a bug. One of my apps uses Full Disk Access, but there is no API to determine whether that has been granted. Some of my code had been assuming that if it could test whether a particular file in a protected folder existed, it must have Full Disk Access. But it turns out that you can do this even without access.
Apple even sort of documents this, saying for -[NSFileManager fileExistsAtPath:] that:
App Sandbox does not restrict which path values may be passed to this parameter.
It’s not really clear what this means because how could the sandbox prevent you from passing a value? So maybe we’re meant to assume that it works for any value. On the other hand, the documentation goes on to say:
If the file at
pathis inaccessible to your app, perhaps because one or more parent directories are inaccessible, this method returnsNO.
This implies that without access you can’t test whether a file exists. But my experience is that you can. (I’ve not looked into whether there’s a difference between the sandbox and TCC protections.)
In any event, whether or not Apple considers this a bug, I think it’s a real privacy issue. If this is the expected behavior, it should be documented so that apps can be designed with this in mind. Maybe apps that store sensitive data should obscure their filenames.
Secondly, why is Apple still investigating this issue a year later? The engineer who designed this should know whether it’s the intended behavior off the top of their head. So the fact that the report didn’t immediately come back as “not a bug” implies that either it is a bug (and one wonders how such a whopper could remain for so long) or that the report is not being actively investigated. Either way, this is more evidence that Apple is not serious about the bug bounty program.
Previously:
- mount_apfs TCC Bypass and Privilege Escalation
- Safari Privacy Protections Bypass
- Mac Sandbox Escape via TextEdit
- Mac Bug Bounty Program Opens
- File System Events Privacy Protections Bypass
- Bypassing Mojave Security Protections
- Mojave’s New Security and Privacy Protections Face Usability Challenges
7 Comments RSS · Twitter
Jeff Johnson is so very antagonistic and dismissive of any attempt at security protections, and tends to describe every potential issue in very hyperbolic terms, so I have to wonder if Apple’s delay here is just that nobody there wants to deal with him.
In any case the core issue seems to be that the TCC sandbox denies file-read-data for the Library/Safari subtree and does not block anything else (such as metadata, which is what lets us stat these files).
It’s unclear if Apple even considers “apps with local filesystem access can determine if you’ve ever visited a given URL” to be a privacy issue. It seems the TCC protection here is really just designed around “prevent apps from reading the website data”.
"nobody there wants to deal with him"
March 24: "We would like to acknowledge Jeff Johnson of underpassapp.com for their assistance." https://support.apple.com/en-us/HT211104
On April 27, Apple Product Security sent me 2 emails, because I had requested a status update on some issues, as Apple itself suggests when you report issues to product security: "We don't automatically provide status updates on issues as we work on them. If you would like an update, please reply to this message and include the Follow-up: number." One of the emails was about my sandbox escape, in which Apple said they didn't see any security implications. https://lapcatsoftware.com/articles/sandbox-escape.html
Thus, if they saw no security implications in my other issue either, then they probably would have said so in the other email that was sent a half hour earlier on that day, instead of saying they were still investigating.
It's kind of incredible to suggest that a $2 trillion corporation acts based on a supposed grudge with a poor little indie dev. I'd love to hear the CEO explain that to the stockholders. If only it were true.
>nobody there wants to deal with him
If that's true, that's the most unprofessional, dangerous thing I've heard in a long time. I highly doubt Apple would intentionally leave security vulnerabilities in their products, and intentionally endanger their customers, just because they don't like the person who reported the issues.
@Lily The Safari local storage data is just an example of potentially sensitive files at a known path. The real issue is that a sandboxed app can get the existence and metadata of (I presume) any file on your Mac that your user account has access to.
I have updated the title of the post to clarify that this is not limited to TCC-protected directories and that, although the sample code uses ls, the issue is really about stat(), not directory listing.
Jeff Johnson is so very antagonistic and dismissive of any attempt at security protections, and tends to describe every potential issue in very hyperbolic terms, so I have to wonder if Apple’s delay here is just that nobody there wants to deal with him
Seriously, you think that Apple behaves like kindergarteners would? "Boo, hoo, hoo, he doesn't agree with us, let's ignore him?"
I'm sure there are plenty of engineers at Apple who think Apple's security theatre is stupid too. It's not their decision, but management's, so they put up with it.
If anything, Mr Johnson could be taken to task for helping Apple further their retrograde idea that computers should be idiot-proof. Users who "think" only in the short term may prefer "app consoles" because they're easier to use. But it leads to a two tier world in which users are expected to be idiots, and corporations (not engineers) get to decide what they can do. Since we are all users of some software or the other, that affects all of us, even those of us who disagree with this trend.
Michael Tsai: "Secondly, why is Apple still investigating this issue a year later?"
- It may not be as binary as you describe. Apple could very well still be crafting a solution (investigating). It can be a bug that they are unsure how to best fix and are taking their time, or it may require a larger solution and it waiting on other development work to be completed in the OS before this can be fixed.
@Michael Do you think it’s reasonable for a bug bounty program to give radio silence in a situation like this? When the fix may be years away or never? I don’t think it’s fair to the reporter, who then can’t publish it without foregoing payment (as happened in this case).
My guess is that Apple has known about this for the 10+ years the sandbox has been around. I can’t see how it would be considered a feature, but there must have been some constraint forced them to implement it this way, and if it hasn’t been fixed in all that time it probably isn’t easy.
