21 ms·

Yet another macOS privacy protections bypass

320 points by maxdesiatov 6y ago

chrisballinger 6y ago
I would appreciate these disclosures a lot more if the author didn’t always include a flippant dismissal of security architecture improvements in macOS. Yes, it’s harder to write software with sandboxing and other modern security techniques, but that doesn’t mean we should go back to how things were.
- gostsamo 6y ago
  At least in this case, the lack of reaction from Apple shows that his accusations are not baseless. Don't blame it on the messenger.
  - Wowfunhappy 6y ago
    My thoughts exactly. If this was just an overlooked bug, which was reported to Apple and which Apple then fixed, that would be the system working as intended. In reality, a very simple bug was reported more than a year ago, and Apple apparently hasn't cared enough to fix it. The only way I can interpret that is to conclude Apple doesn't really care about the integrity of their sandbox. IMO, this more than justifies the author's accusation of "security theater". My browsing history is among the most sensitive data on my machine—certainly more private than anything in my Documents folder, which Apple felt the need to protect in a highly-disruptive way. I agree that it can be worth trading some degree of usability for privacy and security, but only if those privacy benefits are real. If they're not, then we're left in the worst of both worlds. It's really quite damning.
    - floatingatoll 6y ago
      > The only way I can interpret that is to conclude Apple doesn't really care about the integrity of their sandbox. There are many other ways to interpret it. Here is one completely made-up example that I created just now for this reply: "Apple can't lock this down further without breaking open() calls in the majority of existing applications; therefore, they made a pragmatic choice to allow this issue to exist until their long-term roadmap plan to remove direct disk access to protected folders ships in a future macOS update; while declining to share their decision with the reporter, as is completely normal for Apple." If you define "security theater" as "any practice that would not stand up to a human attacker", then all security is guaranteed by definition to be security theater, since all security protections will be found to have weaknesses, compromises, and design decisions that could be theoretically exploited. That definition is clearly non-viable in reality, and so all security decisions — even Apple's — will have unpalatable outcomes that do not invalidate the relevance of security.
      - saagarjha 6y ago
        > while declining to share their decision with the reporter, as is completely normal for Apple This is completely normal for Apple, but that doesn’t make it OK for them to treat security fixes like product launches where they can choose an arbitrary timeline and keep the reporter hanging forever.
        zepto 6y ago
        Sure but it also doesn’t justify innuendo about Apple not caring about privacy. You know as well as I do that this stuff is complicated.
        saagarjha 6y ago
        Yeah, it probably is; maybe it requires substantial changes in the kernel or something. The issue is that Apple never communicates this, they just sit on bugs until they fix them. This is a really poor experience for people reporting issues.
        deleted 6y ago
        [deleted]
  - swiley 6y ago
    These security features are only nominally about protecting the user. Apple implements them to protect their services and platforms from competition and sells them via the privacy argument. Does it happen to improve the security situation? Yes, for many people it does. Is it worth the cost? That's debatable, especially because of Apple's apparent apathy (and occasional hostility) towards the community.
    - matthewmacleod 6y ago
      This is explicitly untrue.
    - heavyset_go 6y ago
      > These security features are only nominally about protecting the user. Apple implements them to protect their services and platforms from competition and sells them via the privacy argument. Stallman[1] and others[2] have talked about just this issue for over a decade now. [1] https://www.gnu.org/philosophy/can-you-trust.en.html https://www.gnu.org/philosophy/can-you-trust.en.html [2] https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
- cle 6y ago
  It's not flippant, read through the author's history: https://lapcatsoftware.com/articles/index.html https://lapcatsoftware.com/articles/index.html This is a serious stance of his, with a lot of serious data and arguments to back it up, from a serious engineer who has written an impressive list of Mac software both for Apple and for Apple's customers.
  - deleted 6y ago
    [deleted]
  - rbrtl 6y ago
    You did use the word serious enough to make it compelling. But the author’s biography doesn’t mean that his comment wasn’t flippant. He’s proved that an well-behaved, codesigned app can list file metadata about files in restricted directories. He hasn’t proven the sandbox compromised. You claim he has so much serious evidence, link us there. Don’t just string adjectives together. I have great respect for Jeff, but he is one of the more outspoken complainant Apple devs. At least he has a better basis for his commentary than DHH.
    - saagarjha 6y ago
      A well behaved, codesigned app being able to list metadata about files in restricted directories is a sandbox compromise. In what viewpoint is it not?
      - rbrtl 6y ago
        As pointed out by the most voted top level comment it's a kernel issue.
        Wowfunhappy 6y ago
        That doesn't mean it's not an issue. I would like Apple to not roll out BS prompts that make my life more difficult until those prompts are actually capable of protecting some of the most sensitive data on my machine.
- _jal 6y ago
  Then you should probably stop reading security disclosures. Security researchers tend not to be terribly considerate of egos. > but that doesn’t mean we should go back I don't think you understand the author's stance.
- barkingcat 6y ago
  Haven't you ever thought that the flippant attitude is exactly why you are able to learn of this now (and not 10 years later/if at all)? If everyone was "policy abiding" folks who will give a megacorp the benefit of the doubt, these won't be disclosed for years. The flippant attitude is exactly why and how you are reading of all these vulnerabilities now. Knowledge of the issue (but enduring "flippancy") or not knowing it at all? You pick. What I'm really saying is that this "flippancy" is the agency that's making someone write a blog post, sign their name to it, put it out there with code samples, etc. You dismissing "flippancy" is insulting the agency of this. Without that emotion, that idea where they thought Apple wasn't treating them well, that is the source where people find the energy to publish, to publicise. Every single word takes strength to write. In this case, the flippancy was the driving force and it shows clearly. Why would you dismiss that energy? And no, it's not the author's job to "shield" you from the wrath of their flippancy. I take it and I thank "flippancy" for disclosing this issue.
- uncomputation 6y ago
  We shouldn’t put the burden on the bug finder to be “nice” and persistent about doing Apple’s job for them. We should put the burden on Apple - the first trillion dollar company - to take bug reports seriously. Given that iOS and macOS have pretty novice security vulnerabilities (allowing apps to view Safari browsing history, allowing iOS apps to detect if a device is jailbroken), why is it up to the bug finder to be nice about it?
zer0w1re 6y ago
Is this also the case when replacing the stock ls binary with the one from GNU coreutils?
- holstvoogd 6y ago
  I think so, looks like a kernel issue more than an ls issue. The kernel should be preventing ls from accessing that metadata
IceWreck 6y ago
> I chose the example of ~/Library/Safari/LocalStorage 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 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. Its a pretty serious issue if any random app can read your browsing history. Even more so that Apple hasnt fixed it more than one year after the author reported it.
- kzrdude 6y ago
  If that is a serious issue, it says a lot about how goalposts have moved the last decades. We haven't been able to expect anything less than every program being able to read all your files.
  - Wowfunhappy 6y ago
    I don't necessarily have an issue with the idea that every app I install can read all my files. It's not great, because it forces me to place a lot of trust in every application, but if the alternative is compromising what those apps can do, or bombarding me with security prompts... well, I can see both sides of that argument. However, if we are going to go down the path of compromising functionality and adding lots of annoying prompts, then that strategy had better actually work! If despite all of these annoyances apps can still read my browsing history, that means I also still need to trust every application I install, so I'd definitely prefer we just went back to where we started.
  - warkdarrior 6y ago
    From early on, Android had strict separation of files across apps. I would think users are generally aware and expecting that apps do not have full access to all of their data.
    - vorpalhex 6y ago
      So many Android apps immediately request file access because they need it for updates, profiles, etc. Users absolutely blindly grant it because it's such a common permission and give it no second thought. The Android sandbox is a terrible example here.
coldtea 6y ago
>I continue to believe that macOS "security" is mainly theater that only impedes the law-abiding Mac software industry while posing little problem for Mac malware. It doesn't take a genius hacker to bypass macOS privacy protections: calling "ls" is a script kiddie level attack. And doing something useful with it, to the level of malware? Is that also trivial? Also, how would that "script kiddie" do that attack in the first place, if you get your apps from the App Store? If it's an independent app, all bets are off anyway. E.g. if they have a serious 0-day to do that, they wouldn't waste time with this. And they could ask the user to disable the SIP, enter root password, or whatever as well...
- Wowfunhappy 6y ago
  > And doing something useful with it, to the level of malware? You probably couldn't use this to steal someone's bank password, but most of TCC doesn't really protect against that. An app could certainly use it to track users and target ads, since it can reveal your browsing history in detail. That probably won't work on the Mac App Store—but the primary complaint about TCC in recent years is that it applies to all software, not just App Store apps.
- johncolanduoni 6y ago
  This limitation also applies to the Safari and Chrome sandboxes on macOS. Being able to get metadata like this off of the system of someone who warrants buying a V8 vulnerability to attack them seems like a reasonable possibility to me.
comex 6y ago
Quick note: The report makes it sound like /bin/ls is being given special privileges. That would be reminiscent of many past macOS security issues: processes are treated differently based on their code signature and entitlements, and sometimes that has unexpected consequences. But that's not the case here. /bin/ls has no entitlements. And if I modify the sample project to just call stat() directly rather than invoking ls, it still works. So it's really a kernel issue where for some reason filesystem metadata is not being protected as much as the actual data.
- joshstrange 6y ago
  > That would be reminiscent of many past macOS security issues: processes are treated differently based on their code signature and entitlements, and sometimes that has unexpected consequences. Hmm, I wonder if this is the root cause of something my friend group found in high school. We had macs that were locked down and I think it was something the system did vs third-party software but I could be mistaken. Pretty much you could only launch certain applications and you couldn't edit and preferences/settings for the system. Being kids we wanted to play Starcraft so I brought in a bunch of copies to play during our free period. Unfortunately you couldn't launch the Starcraft app. I still don't remember how we even figured it out but you could go into Safari and change the default browser to Terminal, then you could open up a word doc, type a link, and click it (or anything that would cause the system to open a link when you weren't already in a browser). That would launch Terminal but with a level of permissions that you couldn't get by launching it directly (or maybe it was that we couldn't even open Terminal directly, it's been a while). Once you had this "system-permissions-Terminal" launched you could type "open /path/to/Starcraft/launcher" and boom, Starcraft would launch and it was off the races. Good times. Our teacher questioned how we could play games and if it was allowed but was placated with the explanation "The computers are all locked down so the ability to play this game means it must be ok to play". A bit of circular-logic and misdirection but this was still in period where all the teachers were woefully behind on technology and how it worked.
  - rbrtl 6y ago
    Hahaha this is great. Reminds me of my first suspension from school when I used MS Word hyperlinks to get to all the drives "hidden" by the network admins. This included the homework mailbox drives, so naturally I found my least favourite teacher's inbox, hid the folder with the work in it and then created a pair of links pointing to one another. Good times. I wouldn't have been found out if I hadn't removed the graphic for the login screen and replaced it with the Christmas version in May... and then bragged about it when everyone in my class noticed.
vmception 6y ago
> The only reason I was even looking for bugs here is that I could have really used the extra money, since it's difficult nowadays to make a living as a Mac developer in the face of ever increasing (and futile) macOS lockdown. Sadly, it's not very difficult to find bugs, though it's extremely difficult to get paid a bounty for them. Prepackage the scripts, weaponize and sell them on White House Market You incur no liability, only the people that penetrate incur some liability and only the people that use the pilfered information incur some different liability Just drop the lone hacker idea, the black hat world functions like a corporation that dilutes and shifts liability until it is no longer recognizable and also worthless to bother with, while everyone perfects their niche and gets paid for that. The white hat world continues undervaluing and resisting market forces.
- Wowfunhappy 6y ago
  Is this really the outcome you want?
  - vmception 6y ago
    I want bug bounties to rise to their market value. I'm willing to accelerate that outcome by pointing out the current market inefficiencies.
my123 6y ago
This bug just lowers the security level at worst to the one present on a regular desktop OS... for the file metadata. I wonder how the fix for that one will look like.
johncolanduoni 6y ago
This limitation of the macOS sandbox has always driven me nuts. Even with a default deny macOS sandbox profile (much stronger than anything that entitlements or TCC can apply, but pretty close to the restrictions some Chrome/Safari processes will run with) you still get an ENOENT instead of EACCESS when trying to access a path that doesn’t exist. I understand not applying that behavior in default sandbox profiles but for apps that are built to run some processes in extremely aggressive sandboxes like browsers it would be a real benefit.
- haruka_ff 6y ago
  BTW, this is also how iOS apps could detect jailbreak status of the device: just try to open paths like `/var/lib/apt`, if it does not exist, it should return ENOENT; otherwise you would know this device is “not clean”. Didn’t think the sandboxing on macOS also has this issue.
Toutouxc 6y ago
Okay, this is a serious issue and I want this to be taken seriously by Apple. What can I, as a reader, do? Is there someone to forward this to? Is there a person in Apple to email? Or are we hoping for a tweet storm to stir the water?
- sofixa 6y ago
  "vote with your wallet" would say some purists.
  - vevans 6y ago
    I don’t know that voting with your wallet works with the richest company in the world, especially when a lot of professionals have to have their devices to do their jobs.
    - juliend2 6y ago
      Voting with your wallet is the crudest & most direct form of power that people have. In a way, it surpasses democracy. So yes, if enough people do it, it does make a difference. The HN crowd in particular has a sizeable influence on other people with regards to technology. Because we are the techies, people ask us what they should use/buy. People observe what knowledgeable people do, and they tend to learn from it. You have more influence than you think. It just takes time to see the changes take effect.
      - Razengan 6y ago
        > In a way, it surpasses democracy. Is there any form of democracy in practice that doesn't involve money? > The HN crowd in particular has a sizeable influence on other people with regards to technology. Because we are the techies, people ask us what they should use/buy. See, many of us do recommend people to buy Apple. Because they're still very much the lesser evil among the Microsofts and Googles. If Apple does go bad, it's ridiculously easy to avoid Apple completely: Just don't buy any Apple hardware. Done. Not so easy with MSFT or GOOG, which is what we warn people about. And that's something the other side on HN can't seem to be able to handle and tries to bury any opposing comments to give the impression of a homogenous echo chamber.
CamJN 6y ago
Up until recently, you could also read the contents of the files after getting the inode number, I got that fixed in Catalina. Good times.
EricE 6y ago
It is a legitimate data leakage issue and I can't say I'm surprised Apple has done nothing on it. Their speed in responding to software issues seems to be more miss than hit :/ I just have to say I had never heard of one of his products - Stop the Madness. A real game changer! The five things he fixes (that vex me routinely!): https://underpassapp.com/StopTheMadness/test.html https://underpassapp.com/StopTheMadness/test.html Yes, you can get various other extensions in other browsers to fix the five issues he addresses, but his extension works in my preferred browser (Safari) and it just works. Didn't have to load a custom script into some other extension or tweak around - just install and done. I've had various success trying to overcome these five issues but my goodness his extension solves them all and so far no site has foiled it. Amazing.
lilyball 6y ago
I don't know how to view specific TCC restrictions, and I don't know of any way to view the full sandbox profile applied to the current app, but in some quick tests it sure looks like the core issue is Apple applied this sandbox rule: (deny file-read-data (home-subpath "/Library/Safari")) when it probably should have done something like (allow file-read-metadata (home-literal "/Library/Safari")) (allow file-read-xattr (home-literal "/Library/Safari")) (deny file-read* (home-subpath "/Library/Safari")) This means you can't enumerate a directory as that's "data", but you can stat individual paths as that's just metadata.
1vuio0pswjnm7 6y ago
"I continue to believe that macOS "security" is mainly theater that only impedes the law-abiding Mac software industry while posing little problem for Mac malware." Unless we use a more specific term such as "user security" I just assume "security" means company security -- the protection of Apple Inc.'s business. One can argue that the security of the business of Apple Inc. benefits its enthusiastically supportive customers. Thus it is possible to conflate "Apple security" with "user security" under the ambiguous term "security". However I think these two concepts are often not interchangeable, and at odds with each other. The user is not the corporation, nor vide versa; they are separate beings with different interests. Neither can speak for the other. Apple now "secures" its BSD-derived OSX from unauthorised software -- unauthorised by Apple Inc., not necessarily unauthorised by the user. As the author notes, this restriction guards against ("impedes") not only malware but all third party software. The same applies with respect to "privacy". Under Apple's definition, there is no such thing as privacy from the company. It is as if the company and the customer are viewed as the same person. Employees of Apple are under strict obligations of confidentiality to the company, but they are under no duty of confidentiality to the customer. When an Apple employee discloses secrets of Apple, Apple can enforce its rights and the employee's obligation via the courts. When Apple discloses the secrets of a customer, the customer has no applicable rights or obligations it can enforce against Apple. Instead, we have seen privacy "theater" as Apple protested, via the courts, against aiding in disclosure; purportedly this was done on behalf of the customer. The truth may be that Apple was acting on its own behalf to protect the business of Apple, Inc.
- jonhohle 6y ago
  > Under Apple's definition, there is no such thing as privacy from the company. What customer privacy is Apple violating customer confidentiality? They have, arguably, the largest end-to-end encrypted messaging system, store user backups and data that they cannot access, are leading in mechanisms to prevent user tracking, and sell hardware specifically designed to reduce data customers are sending to them.
  - declnz 6y ago
    Umm, no. https://www.reuters.com/article/us-apple-fbi-icloud-exclusive/exclusive-apple-dropped-plan-for-encrypting-backups-after-fbi-complained-sources-idUSKBN1ZK1CT https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv... https://sneak.berlin/20201112/your-computer-isnt-yours/ https://sneak.berlin/20201112/your-computer-isnt-yours/

320 points by maxdesiatov 6y ago

I would appreciate these disclosures a lot more if the author didn’t always include a flippant dismissal of security architecture improvements in macOS. Yes, it’s harder to write software with sandboxing and other modern security techniques, but that doesn’t mean we should go back to how things were.

gostsamo 6y ago
At least in this case, the lack of reaction from Apple shows that his accusations are not baseless. Don't blame it on the messenger.
- Wowfunhappy 6y ago
  My thoughts exactly. If this was just an overlooked bug, which was reported to Apple and which Apple then fixed, that would be the system working as intended. In reality, a very simple bug was reported more than a year ago, and Apple apparently hasn't cared enough to fix it. The only way I can interpret that is to conclude Apple doesn't really care about the integrity of their sandbox. IMO, this more than justifies the author's accusation of "security theater". My browsing history is among the most sensitive data on my machine—certainly more private than anything in my Documents folder, which Apple felt the need to protect in a highly-disruptive way. I agree that it can be worth trading some degree of usability for privacy and security, but only if those privacy benefits are real. If they're not, then we're left in the worst of both worlds. It's really quite damning.
  - floatingatoll 6y ago
    > The only way I can interpret that is to conclude Apple doesn't really care about the integrity of their sandbox. There are many other ways to interpret it. Here is one completely made-up example that I created just now for this reply: "Apple can't lock this down further without breaking open() calls in the majority of existing applications; therefore, they made a pragmatic choice to allow this issue to exist until their long-term roadmap plan to remove direct disk access to protected folders ships in a future macOS update; while declining to share their decision with the reporter, as is completely normal for Apple." If you define "security theater" as "any practice that would not stand up to a human attacker", then all security is guaranteed by definition to be security theater, since all security protections will be found to have weaknesses, compromises, and design decisions that could be theoretically exploited. That definition is clearly non-viable in reality, and so all security decisions — even Apple's — will have unpalatable outcomes that do not invalidate the relevance of security.
    - saagarjha 6y ago
      > while declining to share their decision with the reporter, as is completely normal for Apple This is completely normal for Apple, but that doesn’t make it OK for them to treat security fixes like product launches where they can choose an arbitrary timeline and keep the reporter hanging forever.
      - zepto 6y ago
        Sure but it also doesn’t justify innuendo about Apple not caring about privacy. You know as well as I do that this stuff is complicated.
        saagarjha 6y ago
        Yeah, it probably is; maybe it requires substantial changes in the kernel or something. The issue is that Apple never communicates this, they just sit on bugs until they fix them. This is a really poor experience for people reporting issues.
        deleted 6y ago
        [deleted]
- swiley 6y ago
  These security features are only nominally about protecting the user. Apple implements them to protect their services and platforms from competition and sells them via the privacy argument. Does it happen to improve the security situation? Yes, for many people it does. Is it worth the cost? That's debatable, especially because of Apple's apparent apathy (and occasional hostility) towards the community.
  - matthewmacleod 6y ago
    This is explicitly untrue.
  - heavyset_go 6y ago
    > These security features are only nominally about protecting the user. Apple implements them to protect their services and platforms from competition and sells them via the privacy argument. Stallman[1] and others[2] have talked about just this issue for over a decade now. [1] https://www.gnu.org/philosophy/can-you-trust.en.html https://www.gnu.org/philosophy/can-you-trust.en.html [2] https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
cle 6y ago
It's not flippant, read through the author's history: https://lapcatsoftware.com/articles/index.html https://lapcatsoftware.com/articles/index.html This is a serious stance of his, with a lot of serious data and arguments to back it up, from a serious engineer who has written an impressive list of Mac software both for Apple and for Apple's customers.
- deleted 6y ago
  [deleted]
- rbrtl 6y ago
  You did use the word serious enough to make it compelling. But the author’s biography doesn’t mean that his comment wasn’t flippant. He’s proved that an well-behaved, codesigned app can list file metadata about files in restricted directories. He hasn’t proven the sandbox compromised. You claim he has so much serious evidence, link us there. Don’t just string adjectives together. I have great respect for Jeff, but he is one of the more outspoken complainant Apple devs. At least he has a better basis for his commentary than DHH.
  - saagarjha 6y ago
    A well behaved, codesigned app being able to list metadata about files in restricted directories is a sandbox compromise. In what viewpoint is it not?
    - rbrtl 6y ago
      As pointed out by the most voted top level comment it's a kernel issue.
      - Wowfunhappy 6y ago
        That doesn't mean it's not an issue. I would like Apple to not roll out BS prompts that make my life more difficult until those prompts are actually capable of protecting some of the most sensitive data on my machine.
_jal 6y ago
Then you should probably stop reading security disclosures. Security researchers tend not to be terribly considerate of egos. > but that doesn’t mean we should go back I don't think you understand the author's stance.
barkingcat 6y ago
Haven't you ever thought that the flippant attitude is exactly why you are able to learn of this now (and not 10 years later/if at all)? If everyone was "policy abiding" folks who will give a megacorp the benefit of the doubt, these won't be disclosed for years. The flippant attitude is exactly why and how you are reading of all these vulnerabilities now. Knowledge of the issue (but enduring "flippancy") or not knowing it at all? You pick. What I'm really saying is that this "flippancy" is the agency that's making someone write a blog post, sign their name to it, put it out there with code samples, etc. You dismissing "flippancy" is insulting the agency of this. Without that emotion, that idea where they thought Apple wasn't treating them well, that is the source where people find the energy to publish, to publicise. Every single word takes strength to write. In this case, the flippancy was the driving force and it shows clearly. Why would you dismiss that energy? And no, it's not the author's job to "shield" you from the wrath of their flippancy. I take it and I thank "flippancy" for disclosing this issue.
uncomputation 6y ago
We shouldn’t put the burden on the bug finder to be “nice” and persistent about doing Apple’s job for them. We should put the burden on Apple - the first trillion dollar company - to take bug reports seriously. Given that iOS and macOS have pretty novice security vulnerabilities (allowing apps to view Safari browsing history, allowing iOS apps to detect if a device is jailbroken), why is it up to the bug finder to be nice about it?

zer0w1re 6y ago

Is this also the case when replacing the stock ls binary with the one from GNU coreutils?

holstvoogd 6y ago
I think so, looks like a kernel issue more than an ls issue. The kernel should be preventing ls from accessing that metadata

IceWreck 6y ago

> I chose the example of ~/Library/Safari/LocalStorage 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 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. Its a pretty serious issue if any random app can read your browsing history. Even more so that Apple hasnt fixed it more than one year after the author reported it.

kzrdude 6y ago
If that is a serious issue, it says a lot about how goalposts have moved the last decades. We haven't been able to expect anything less than every program being able to read all your files.
- Wowfunhappy 6y ago
  I don't necessarily have an issue with the idea that every app I install can read all my files. It's not great, because it forces me to place a lot of trust in every application, but if the alternative is compromising what those apps can do, or bombarding me with security prompts... well, I can see both sides of that argument. However, if we are going to go down the path of compromising functionality and adding lots of annoying prompts, then that strategy had better actually work! If despite all of these annoyances apps can still read my browsing history, that means I also still need to trust every application I install, so I'd definitely prefer we just went back to where we started.
- warkdarrior 6y ago
  From early on, Android had strict separation of files across apps. I would think users are generally aware and expecting that apps do not have full access to all of their data.
  - vorpalhex 6y ago
    So many Android apps immediately request file access because they need it for updates, profiles, etc. Users absolutely blindly grant it because it's such a common permission and give it no second thought. The Android sandbox is a terrible example here.

coldtea 6y ago

>I continue to believe that macOS "security" is mainly theater that only impedes the law-abiding Mac software industry while posing little problem for Mac malware. It doesn't take a genius hacker to bypass macOS privacy protections: calling "ls" is a script kiddie level attack. And doing something useful with it, to the level of malware? Is that also trivial? Also, how would that "script kiddie" do that attack in the first place, if you get your apps from the App Store? If it's an independent app, all bets are off anyway. E.g. if they have a serious 0-day to do that, they wouldn't waste time with this. And they could ask the user to disable the SIP, enter root password, or whatever as well...

Wowfunhappy 6y ago
> And doing something useful with it, to the level of malware? You probably couldn't use this to steal someone's bank password, but most of TCC doesn't really protect against that. An app could certainly use it to track users and target ads, since it can reveal your browsing history in detail. That probably won't work on the Mac App Store—but the primary complaint about TCC in recent years is that it applies to all software, not just App Store apps.
johncolanduoni 6y ago
This limitation also applies to the Safari and Chrome sandboxes on macOS. Being able to get metadata like this off of the system of someone who warrants buying a V8 vulnerability to attack them seems like a reasonable possibility to me.

comex 6y ago

Quick note: The report makes it sound like /bin/ls is being given special privileges. That would be reminiscent of many past macOS security issues: processes are treated differently based on their code signature and entitlements, and sometimes that has unexpected consequences. But that's not the case here. /bin/ls has no entitlements. And if I modify the sample project to just call stat() directly rather than invoking ls, it still works. So it's really a kernel issue where for some reason filesystem metadata is not being protected as much as the actual data.

joshstrange 6y ago
> That would be reminiscent of many past macOS security issues: processes are treated differently based on their code signature and entitlements, and sometimes that has unexpected consequences. Hmm, I wonder if this is the root cause of something my friend group found in high school. We had macs that were locked down and I think it was something the system did vs third-party software but I could be mistaken. Pretty much you could only launch certain applications and you couldn't edit and preferences/settings for the system. Being kids we wanted to play Starcraft so I brought in a bunch of copies to play during our free period. Unfortunately you couldn't launch the Starcraft app. I still don't remember how we even figured it out but you could go into Safari and change the default browser to Terminal, then you could open up a word doc, type a link, and click it (or anything that would cause the system to open a link when you weren't already in a browser). That would launch Terminal but with a level of permissions that you couldn't get by launching it directly (or maybe it was that we couldn't even open Terminal directly, it's been a while). Once you had this "system-permissions-Terminal" launched you could type "open /path/to/Starcraft/launcher" and boom, Starcraft would launch and it was off the races. Good times. Our teacher questioned how we could play games and if it was allowed but was placated with the explanation "The computers are all locked down so the ability to play this game means it must be ok to play". A bit of circular-logic and misdirection but this was still in period where all the teachers were woefully behind on technology and how it worked.
- rbrtl 6y ago
  Hahaha this is great. Reminds me of my first suspension from school when I used MS Word hyperlinks to get to all the drives "hidden" by the network admins. This included the homework mailbox drives, so naturally I found my least favourite teacher's inbox, hid the folder with the work in it and then created a pair of links pointing to one another. Good times. I wouldn't have been found out if I hadn't removed the graphic for the login screen and replaced it with the Christmas version in May... and then bragged about it when everyone in my class noticed.

vmception 6y ago

> The only reason I was even looking for bugs here is that I could have really used the extra money, since it's difficult nowadays to make a living as a Mac developer in the face of ever increasing (and futile) macOS lockdown. Sadly, it's not very difficult to find bugs, though it's extremely difficult to get paid a bounty for them. Prepackage the scripts, weaponize and sell them on White House Market You incur no liability, only the people that penetrate incur some liability and only the people that use the pilfered information incur some different liability Just drop the lone hacker idea, the black hat world functions like a corporation that dilutes and shifts liability until it is no longer recognizable and also worthless to bother with, while everyone perfects their niche and gets paid for that. The white hat world continues undervaluing and resisting market forces.

Wowfunhappy 6y ago
Is this really the outcome you want?
- vmception 6y ago
  I want bug bounties to rise to their market value. I'm willing to accelerate that outcome by pointing out the current market inefficiencies.

my123 6y ago

This bug just lowers the security level at worst to the one present on a regular desktop OS... for the file metadata. I wonder how the fix for that one will look like.

johncolanduoni 6y ago

This limitation of the macOS sandbox has always driven me nuts. Even with a default deny macOS sandbox profile (much stronger than anything that entitlements or TCC can apply, but pretty close to the restrictions some Chrome/Safari processes will run with) you still get an ENOENT instead of EACCESS when trying to access a path that doesn’t exist. I understand not applying that behavior in default sandbox profiles but for apps that are built to run some processes in extremely aggressive sandboxes like browsers it would be a real benefit.

haruka_ff 6y ago
BTW, this is also how iOS apps could detect jailbreak status of the device: just try to open paths like `/var/lib/apt`, if it does not exist, it should return ENOENT; otherwise you would know this device is “not clean”. Didn’t think the sandboxing on macOS also has this issue.

Toutouxc 6y ago

Okay, this is a serious issue and I want this to be taken seriously by Apple. What can I, as a reader, do? Is there someone to forward this to? Is there a person in Apple to email? Or are we hoping for a tweet storm to stir the water?

sofixa 6y ago
"vote with your wallet" would say some purists.
- vevans 6y ago
  I don’t know that voting with your wallet works with the richest company in the world, especially when a lot of professionals have to have their devices to do their jobs.
  - juliend2 6y ago
    Voting with your wallet is the crudest & most direct form of power that people have. In a way, it surpasses democracy. So yes, if enough people do it, it does make a difference. The HN crowd in particular has a sizeable influence on other people with regards to technology. Because we are the techies, people ask us what they should use/buy. People observe what knowledgeable people do, and they tend to learn from it. You have more influence than you think. It just takes time to see the changes take effect.
    - Razengan 6y ago
      > In a way, it surpasses democracy. Is there any form of democracy in practice that doesn't involve money? > The HN crowd in particular has a sizeable influence on other people with regards to technology. Because we are the techies, people ask us what they should use/buy. See, many of us do recommend people to buy Apple. Because they're still very much the lesser evil among the Microsofts and Googles. If Apple does go bad, it's ridiculously easy to avoid Apple completely: Just don't buy any Apple hardware. Done. Not so easy with MSFT or GOOG, which is what we warn people about. And that's something the other side on HN can't seem to be able to handle and tries to bury any opposing comments to give the impression of a homogenous echo chamber.

CamJN 6y ago

Up until recently, you could also read the contents of the files after getting the inode number, I got that fixed in Catalina. Good times.

EricE 6y ago

It is a legitimate data leakage issue and I can't say I'm surprised Apple has done nothing on it. Their speed in responding to software issues seems to be more miss than hit :/ I just have to say I had never heard of one of his products - Stop the Madness. A real game changer! The five things he fixes (that vex me routinely!): https://underpassapp.com/StopTheMadness/test.html https://underpassapp.com/StopTheMadness/test.html Yes, you can get various other extensions in other browsers to fix the five issues he addresses, but his extension works in my preferred browser (Safari) and it just works. Didn't have to load a custom script into some other extension or tweak around - just install and done. I've had various success trying to overcome these five issues but my goodness his extension solves them all and so far no site has foiled it. Amazing.

lilyball 6y ago

I don't know how to view specific TCC restrictions, and I don't know of any way to view the full sandbox profile applied to the current app, but in some quick tests it sure looks like the core issue is Apple applied this sandbox rule: (deny file-read-data (home-subpath "/Library/Safari")) when it probably should have done something like (allow file-read-metadata (home-literal "/Library/Safari")) (allow file-read-xattr (home-literal "/Library/Safari")) (deny file-read* (home-subpath "/Library/Safari")) This means you can't enumerate a directory as that's "data", but you can stat individual paths as that's just metadata.

1vuio0pswjnm7 6y ago

"I continue to believe that macOS "security" is mainly theater that only impedes the law-abiding Mac software industry while posing little problem for Mac malware." Unless we use a more specific term such as "user security" I just assume "security" means company security -- the protection of Apple Inc.'s business. One can argue that the security of the business of Apple Inc. benefits its enthusiastically supportive customers. Thus it is possible to conflate "Apple security" with "user security" under the ambiguous term "security". However I think these two concepts are often not interchangeable, and at odds with each other. The user is not the corporation, nor vide versa; they are separate beings with different interests. Neither can speak for the other. Apple now "secures" its BSD-derived OSX from unauthorised software -- unauthorised by Apple Inc., not necessarily unauthorised by the user. As the author notes, this restriction guards against ("impedes") not only malware but all third party software. The same applies with respect to "privacy". Under Apple's definition, there is no such thing as privacy from the company. It is as if the company and the customer are viewed as the same person. Employees of Apple are under strict obligations of confidentiality to the company, but they are under no duty of confidentiality to the customer. When an Apple employee discloses secrets of Apple, Apple can enforce its rights and the employee's obligation via the courts. When Apple discloses the secrets of a customer, the customer has no applicable rights or obligations it can enforce against Apple. Instead, we have seen privacy "theater" as Apple protested, via the courts, against aiding in disclosure; purportedly this was done on behalf of the customer. The truth may be that Apple was acting on its own behalf to protect the business of Apple, Inc.

jonhohle 6y ago
> Under Apple's definition, there is no such thing as privacy from the company. What customer privacy is Apple violating customer confidentiality? They have, arguably, the largest end-to-end encrypted messaging system, store user backups and data that they cannot access, are leading in mechanisms to prevent user tracking, and sell hardware specifically designed to reduce data customers are sending to them.
- declnz 6y ago
  Umm, no. https://www.reuters.com/article/us-apple-fbi-icloud-exclusive/exclusive-apple-dropped-plan-for-encrypting-backups-after-fbi-complained-sources-idUSKBN1ZK1CT https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv... https://sneak.berlin/20201112/your-computer-isnt-yours/ https://sneak.berlin/20201112/your-computer-isnt-yours/