Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yet another macOS privacy protections bypass

lapcatsoftware.com

Post reply on HN
Print view View original

11–20 of 94 posts

Re: Yet another macOS privacy protections bypass

#11

Post by coldtea »

>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...

Re: Yet another macOS privacy protections bypass

#12

Post by comex »

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.

Re: Yet another macOS privacy protections bypass

#13

Post by [deleted] »

cle wrote: post #9
chrisballinger wrote: post #2

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.

It's not flippant, read through the author's history: 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]

Re: Yet another macOS privacy protections bypass

#14

Post by Wowfunhappy »

coldtea wrote: post #11

> 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 th…

> 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.

Re: Yet another macOS privacy protections bypass

#15

Post by floatingatoll »

Wowfunhappy wrote: post #5
gostsamo wrote: post #4

Earlier quoted context omitted.

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.

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 t…

> 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.

Re: Yet another macOS privacy protections bypass

#16

Post by Wowfunhappy »

kzrdude wrote: post #10
IceWreck wrote: post #8

> 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 histor…

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.

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.

Re: Yet another macOS privacy protections bypass

#17

Post by _4msi »

cle wrote: post #9
chrisballinger wrote: post #2

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.

It's not flippant, read through the author's history: 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.

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.

Re: Yet another macOS privacy protections bypass

#19

Post by _jal »

chrisballinger wrote: post #2

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.

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.

Re: Yet another macOS privacy protections bypass

#20

Post by vmception »

> 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.

Post reply on HN