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

51–60 of 94 posts

Re: Yet another macOS privacy protections bypass

#51

Post by joshstrange »

comex wrote: post #48
joshstrange wrote: post #39

Earlier quoted context omitted.

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

How long ago was this?

Hmm, let's see. It would have been 2004-2008 IIRC. I think I did it at the tail end of that time period though. I want to say that it was on the gumdrop shaped macs but I know the school got some of the first iMacs around that time as well. The new iMacs were awesome to me because I could carry around an external hard drive and boot the newest macOS (Mac OS then) off it. It meant I had root and that coupled with a proxy gave me a fully unlocked computer.

Re: Yet another macOS privacy protections bypass

#52

Post by haruka_ff »

johncolanduoni wrote: post #22

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…

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.

Re: Yet another macOS privacy protections bypass

#53

Post by barkingcat »

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.

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.

Re: Yet another macOS privacy protections bypass

#54

Post by vorpalhex »

warkdarrior wrote: post #23
kzrdude wrote: post #10

Earlier quoted context omitted.

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.

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.

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.

Re: Yet another macOS privacy protections bypass

#55

Post by dubya »

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…

Just out of curiosity, is there an allowed way to access directories like this? Sudo doesn't let me see the contents of the ~/Library/Safari directory. Can non-Apple programs access this, like backup programs? Can I bless a script to access this? Can Mozilla or others import bookmarks from Safari any more?

Re: Yet another macOS privacy protections bypass

#56

Post by uncomputation »

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.

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?

Re: Yet another macOS privacy protections bypass

#58

Post by Razengan »

joshstrange wrote: post #39
comex wrote: post #12

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

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

Not related to Macs but coincidentally StarCraft was also the first time ever I "cracked" a game. ^^

For whatever reason, the copy protection was not recognizing my game disc (apparently only worked on Windows 95 but not 98 as I found later).

This was my most anticipated game yet, so I made myself learn Windows/PC debugging on the spot — without the internet — which basically amounted to single-stepping through every line of disassembly in Visual Studio until the disc error message, then working backwards from the very last "jump" instruction, flipping the condition of each jump (I think it was JZ to JNZ or vice versa), until finally I found the 2 bytes (or was it 4) that took me to the blessed menu music that I can still recall. :)

Of course I had nobody to show my achievement off to and it wasn't even a moment of pride or anything, just relief and sheer happiness as I was about to get lost in what would become one of my most favorite games of all time.

(P.S. I hate what they did to the story in StarCraft II)

Re: Yet another macOS privacy protections bypass

#59

Post by hnlmorg »

joshstrange wrote: post #51
comex wrote: post #48

Earlier quoted context omitted.

How long ago was this?

Hmm, let's see. It would have been 2004-2008 IIRC. I think I did it at the tail end of that time period though. I want to say that it was on the gumdrop shaped macs but I know the school got some of the first iMacs around that time as well. The new iMacs were awesome to me because I could carry around an external hard drive and boot the newest macOS (Mac OS then) off it. It meant I had root and that coupled with a pr…

> I want to say that it was on the gumdrop shapes macs but I know the school got some of the first iMacs around that time as well.

The "gumdrop shaped macs" were the first iMacs and were released in 1998 (I remember this well because that was around the time I worked for a publishing company so had to deal with MacOS 8 and 9 a lot as well as wiring a gigabit Apple Talk network (at the time that was very futuristic).

I had similar tails of exploiting my school network. Though it was Windows 3 and I way playing Wolf3D loaded via a program called something like "Object Manager" that allowed you to embed data into winword (might have been related to OLE?). Those machines were null terminals so the game was installed into my user area. Unsurprisingly I got caught but thankfully deleted the executable just moments before hand so I only had to make an excuse for the WAD files.

At college I upped my game and write a RAT which I installed on every PC on the network. I actually managed to get away with that one, albeit there were a couple of near misses. One time I got caught because some mates sat next to me were playing games. When questioned what I was doing I confessed to the lesser crime of also playing games because writing malware would surely have seen me suspended (or worse) rather than having my IT privileges revoked for 24 hours! That college did eventually find the RAT on the network but only after I left, but assumed it was someone else. It wasn't until my brother got a job at the college IT department ~5 years later when they realised it was me who installed the software.

Re: Yet another macOS privacy protections bypass

#60

Post by shuckles »

dubya wrote: post #55
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…

Just out of curiosity, is there an allowed way to access directories like this? Sudo doesn't let me see the contents of the ~/Library/Safari directory. Can non-Apple programs access this, like backup programs? Can I bless a script to access this? Can Mozilla or others import bookmarks from Safari any more?

The report shows that given a path, any app can access file metadata or learn that no such file exists outside the sandbox. It does not show access to file data itself. The Safari specific part of the report is data leak caused by the fact that Safari embeds sensitive information (URLs) into file metadata (name).

I believe you can access those directories by either enabling Full Disk Access for the process of interest or by disabling System Integrity Protection.

Post reply on HN