3 ms·
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 co
by Thorrez 6y 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?
- FPGAhacker 6y agoIsn't that the point of sandboxing?
- fedorareis 6y agoI 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.
- olliej 6y agoData vaults are different, think of them as an ACL around (user, application) pairs.
- olliej 6y agoData 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.
- Thorrez 6y agoInteresting, 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.
- sukilot 6y agoMacOS is evolving toward the sane Browser/iOS/Android security model for networked computers running apps from diverse third parties.
- xnyhps 6y agoTo 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.
- olliej 6y agoIs 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
- FreakLegion 6y ago> 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 https://en.wikipedia.org/wiki/XcodeGhost.
- gridlockd 6y agoThe underrated risk of making your SDK so huge and inaccessible that people would rather get it from untrusted sources.
- panpanna 6y agoIn this case it was partially due to issues with the great Chinese firewall.
- JimDabell 6y agoXcodeGhost 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.
- FreakLegion 6y agoXcodeGhost 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.