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

71–80 of 94 posts

Re: Yet another macOS privacy protections bypass

#71

Post by zepto »

saagarjha wrote: post #67
zepto wrote: post #62

Earlier quoted context omitted.

The biggest issue with the author is that he complains both about the controlling/locked down nature of Apple’s platforms and about any bugs that show up in that system. I.e. His goal is to criticize Apple no matter what they do , because he dislikes the fact that they are no longer producing the kind of open system he prefers.

I think the angle he has is “Apple should remove these protections because they can’t implement them correctly”.

Yeah, which doesn’t seem reasonable, especially when mixed in with a bunch of assumptions about ill intent.

There are an enormous number of protections and a small number of issues, which do eventually get fixed, and of course the threats are undeniable.

However you are right that Apple is notoriously had at communicating about bugs.

Re: Yet another macOS privacy protections bypass

#72

Post by EricE »

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

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.

Re: Yet another macOS privacy protections bypass

#73

Post by EricE »

saagarjha wrote: post #66
codezero wrote: post #36

Earlier quoted context omitted.

I think they are implying apple can’t control the sensitivity of third party tools across the board, so it’s up to chrome to figure out how to protect your browsing history, and they need to improve their file system layout or APIs to protect their users.

Safari uses APIs to protect its data directory that isn’t made available to third-party apps.

And those aren't good enough as he was able to bypass them with ls - command line tool ran without privilege inside of a sandboxed app.

This is a serious issue for data leakage.

Re: Yet another macOS privacy protections bypass

#74

Post by joshstrange »

hnlmorg wrote: post #59
joshstrange wrote: post #51

Earlier quoted context omitted.

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

> The "gumdrop shaped macs" were the first iMacs and were released in 1998

Ahh, my bad. This was early-days for my "paying attention to macs". I only used them at all because that was all the school had, I was a die-hard, PC-master-race, build-your-own-computer, windows user at this point. So yeah, we had the gumdrop shaped iMacs and then we upgraded to the chunky white-bodied-on-a-stand iMacs. We did have a few Mac Pros in the library (for video editing) and in the shop class (for 3D modeling), the cheesegrater style ones.

Re: Yet another macOS privacy protections bypass

#75

Post by lilyball »

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.

Re: Yet another macOS privacy protections bypass

#76

Post by vmception »

Wowfunhappy wrote: post #70
vmception wrote: post #20

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

Is this really the outcome you want?

I want bug bounties to rise to their market value. I'm willing to accelerate that outcome by pointing out the current market inefficiencies.

Re: Yet another macOS privacy protections bypass

#77

Post by dubya »

shuckles wrote: post #60
dubya wrote: post #55

Earlier quoted context omitted.

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

Thanks. "macos full disk access" seem to be the magic keywords for find out about this.

Re: Yet another macOS privacy protections bypass

#78

Post by stordoff »

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…

> gave me a fully unlocked computer

In a way, the ever-increasing restrictions during my final year at school pushed us into exploiting various flaws in their setup for a couple of reasons. Primarily, they were arduous - by the middle of the year, any window with a title containing certain strings, even ones as innocuous as "Firefox", would be closed automatically without warning. It got in the way of legitimate activities - a number of teachers also found ways to avoid them as sites they needed were often blocked. It was also interesting to keep having to find new ways to get around it ("CGI proxies"[1] found via Google -> self-hosted proxies -> wildcard domains to bypass filter lists -> access via IP and random port -> local admin exploit to disable protection/monitoring software).

In the process, we discovered that the security was rather inadequate. A VNC server was installed on all machines, including staff machines, with the very imaginative password of "vnc" (not hard to guess once you see a member of staff typing in a three character password), and we shoulder-surfed a domain admin password and it was just "school". This was later changed[2], but we bruteforced a cached hash[3] and found it was just the name of the school with a '0' in place of an 'o'. We had a 'shadow' domain admin account for _months_ before it was noticed, even after the staff were aware people were poking at holes in the system (someone else had sent a Window messenger service message to the entire domain around the same time).

We never really used it for anything though - we created the domain admin account to see if we could, then it basically went unused after that. We only got caught after someone else used a script to change the local admin password on every computer (I'm still not entirely sure why). It did provide an interesting lesson in OPSEC though - it was only tied back to us as they were tracking USD device names, and someone called their USB drive " USB" and still had it connected when logging into the domain admin account.

The punishment was to spend a week working with the IT technicians (mostly doing busy work such as cable managing rooms and tracking down serial numbers/asset tags), which gave us plenty of time to fully explain the flaws we found. I think they took security more seriously after that.

[1] https://www.jmarshall.com/tools/cgiproxy/

[2] we had no malicious intent, so upon realising that gave you read/write access to everyone's files, we left an anonymous note containing the login details at the IT technicians' office hoping they would improve things. Some of the teaching staff were also aware, and their only advice was essentially "Don't get caught" (and one asked for a copy of the Ophcrack live CD).

[3] Booted from an Ophcrack live CD, something that was "fixed" by removing the CD drive from every machine in the school

Re: Yet another macOS privacy protections bypass

#79

Post by 1vuio0pswjnm7 »

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

Re: Yet another macOS privacy protections bypass

#80

Post by sickmate »

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…

You could also open restricted system preference panes by searching for a relevant term in Spotlight and going to a User Guide article. Often they would have a link to open the preference pane which would bypass any restrictions.
Post reply on HN