{"id":30934,"date":"2020-12-07T16:30:25","date_gmt":"2020-12-07T21:30:25","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=30934"},"modified":"2021-07-13T11:53:37","modified_gmt":"2021-07-13T15:53:37","slug":"tcc-doesnt-prevent-protected-folders-from-being-listed","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/12\/07\/tcc-doesnt-prevent-protected-folders-from-being-listed\/","title":{"rendered":"Sandbox Doesn’t Protect Files From stat()"},"content":{"rendered":"

Jeff Johnson<\/a> (tweet<\/a>, Hacker News<\/a>):<\/p>\n

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.<\/p>

[…]<\/p>

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.<\/p>

[…]<\/p>

I chose the example of ~\/Library\/Safari\/LocalStorage<\/code> because Safari names the files in this directory according to the web sites that you visit! Also note that the output of long format ls -l<\/code> contains the last modification date of the files. Thus, one possible privacy violation from this technique is to learn the user’s web browsing history.<\/p><\/blockquote>\n

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.<\/p>\n

Apple even sort of documents this<\/a>, saying for -[NSFileManager fileExistsAtPath:]<\/code> that:<\/p>\n

App Sandbox does not restrict which path values may be passed to this parameter.<\/p><\/blockquote>\n

It’s not really clear what this means because how could the sandbox prevent you from passing<\/em> a value? So maybe we’re meant to assume that it works<\/em> for any value. On the other hand, the documentation goes on to say:<\/p>\n

If the file at path<\/code> is inaccessible to your app, perhaps because one or more parent directories are inaccessible, this method returns NO<\/code>.<\/p><\/blockquote>\n

This implies that without access you can’t<\/em> test whether a file exists. But my experience is that you can<\/em>. (I’ve not looked into whether there’s a difference between the sandbox and TCC protections.)<\/p>\n

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.<\/p>\n

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.<\/p>\n\n

Previously:<\/p>\n