Hacker News new | ask | show | jobs
by Thorrez 2132 days ago
Wow, the way it spreads is fascinating, reminiscent of Reflections on Trusting Trust.

I'm a bit confused about

>two zero-day exploits: one is used to steal cookies via a flaw in the behavior of Data Vaults, another is used to abuse the development version of Safari.

Malware on the local machine can steal data from Safari on the local machine. Is that a surprise? Does Safari have a threat model that it intends to protect against locally running malware?

3 comments

Data vaults on macOS are intended to prevent apps running under they same unprivileged user from accessing files that belong to another app.

Eg, if there is a file/directory that only safari is meant to have access to, no other app should be able to read it, without at least bringing up one of the annoying “allow X to access your Y”. For example, the first time you, say, feel your home directory you’ll get a bunch of TCC requests asking if the host app (Terminal.app say) should be allowed to access those files.

To add to this: there are two different types of Data Vaults. For locations such as ~/Pictures, ~/Documents, Calendars, Contacts, etc. a permission prompt is triggered if an app tries to access it. Other locations, such as where Mail and Safari keep their data, can not be allowed from a prompt. Those require "Full Disk Access" for third-party software to gain access, which you should give only to applications that really need it, such as a backup tool.

Anything not on those locations is not protected, so there's no Data Vault for Chrome's cookie file, for example.

Is there an API that allows apps to construct data vaults? I assumed that there would be, but I also generally don't write code at that level in the stack
Interesting, macOS has a much stricter permission system than I'm used to on Windows and Linux. On Windows and Linux malware could just start controlling the mouse and keyboard and thus control the browser to get data from it, but on macOS apparently to control the mouse and keyboard some special permission is needed.
MacOS is evolving toward the sane Browser/iOS/Android security model for networked computers running apps from diverse third parties.
> Wow, the way it spreads is fascinating, reminiscent of Reflections on Trusting Trust.

Interestingly it's happened to Xcode before, and an impressive number of bad apps made it to the App Store as a result. See https://en.wikipedia.org/wiki/XcodeGhost.

XcodeGhost wasn’t an attack like this. That was a compromised version of Xcode. This doesn’t require a compromised version of Xcode; it infects Xcode projects. To perhaps put it into more familiar terms, this is as if a malicious Makefile goes around rewriting other Makefiles to include itself.
XcodeGhost was an attack like this in the context of Thompson's lecture, mentioned by Thorrez. Neither fully lives up to Thompson's premise, though. XcodeGhost is the closer of the two.
The underrated risk of making your SDK so huge and inaccessible that people would rather get it from untrusted sources.
In this case it was partially due to issues with the great Chinese firewall.
Isn't that the point of sandboxing?
I was always under the impression that the point of sandboxing was to keep an application exploit from compromising the system. Not to keep the application safe from the system.
Data vaults are different, think of them as an ACL around (user, application) pairs.