CVE-2024-40798 – an app may be able to read Safari's browsing history | Hacker News Reader

CVE-2024-40798 – an app may be able to read Safari's browsing history

nvd.nist.gov

22 pointskeepamovin12 comments

This is only a vulnerability because macOS actually tries to sandbox access to user data (photos, documents, etc). On Windows or Linux being able to access all a user's data is expected, and thus spyware and ransomware don't even need administrator privileges to wreak havock. So, a win for Apple here.

I understand that this is considered a vulnerability on iOS, since its security model includes isolating applications from each other.

But does macOS even attempt to sandbox applications like that? I assumed it's like Windows/Linux where traditionally applications have full access to a user's data and it only attempts to protect data of other users. On Windows/Linux attempts to introduce such isolation have seen little adoption so far. Has Apple been more successful on macOS?

Yes, Mac app store applications have a sandbox that restricts access to user files unless the user authorized it.

https://book.hacktricks.xyz/macos-hardening/macos-security-a...

There is some sandboxing on Mac. For example, there is a bunch of permissions around Full Disk Access that prevents a rogue app from getting full access to all your files without your approval

macOS has sandboxing in the "prevent attacker from escalating from the compromised process" sense.

It also has the concept of data that can only be read by apps that have the correctly rights - as in even if a process is running as root, the process cannot access the data.

It sounds like someone found some way to access the history data, and because they're not supposed to be able to, there's a CVE.

Of course if there was no attempt to protect the browsing history so anything/one could read it, then that would not be a vulnerability, so that's fun :-/ (as analogy: one company releases a car with a key required to open+drive, another company releases a car with no locks that anyone can get into a drive off with, and then someone finds a way to pick the lock on the former).

Before you panic:

> This issue is fixed in macOS Sonoma 14.6, iOS 16.7.9 and iPadOS 16.7.9, macOS Monterey 12.7.6, macOS Ventura 13.6.8.

Okay now you can panic. But at least if your devices are up to date, it's fixed now...

I'd like to see this run back to back with those recent Apple commercials.

It will soon be forgotten and people will still think apple cares about privacy.

While I can't comment on how truly Apple cares about privacy, a bug is not the same as an intentional decision. This seems like a weird thing to fixate on as an example of Apple not caring about privacy.

Would you say the same about the lack of root password earlier?

Was it an intentional decision?

yet another instance where apple's unclear support policies will cause more confusion. Was iOS 15 impacted, and will this be backported? Nobody knows. 15.8.3 was announced the same day as 16.7.9 but with zero CVE notes, so if you have one of these: iPhone 6s (all models), iPhone 7 (all models), iPhone SE (1st generation), iPad Air 2, iPad mini (4th generation), and iPod touch (7th generation), it is unclear if you're receiving security fixes.

Reply on news.ycombinator.com