Safari 15 IndexedDB Information Leaks
Martin Bajanik (Hacker News, MacRumors):
In this article, we discuss a software bug introduced in Safari 15’s implementation of the IndexedDB API that lets any website track your internet activity and even reveal your identity.
[…]
In Safari 15 on macOS, and in all browsers on iOS and iPadOS 15, the IndexedDB API is violating the same-origin policy. Every time a website interacts with a database, a new (empty) database with the same name is created in all other active frames, tabs, and windows within the same browser session.
[…]
The fact that database names leak across different origins is an obvious privacy violation. It lets arbitrary websites learn what websites the user visits in different tabs or windows. This is possible because database names are typically unique and website-specific. Moreover, we observed that in some cases, websites use unique user-specific identifiers in database names. This means that authenticated users can be uniquely and precisely identified.
[…]
In this case, private mode in Safari 15 is also affected by the leak.
[…]
Apple engineers began working on the bug as of Sunday, have merged potential fixes, and have marked our report as resolved. However, the bug continues to persist for end users until these changes are released.
The bug was originally reported in November.
This is a huge bug. On OSX, Safari users can (temporarily) switch to another browser to avoid their data leaking across origins. iOS users have no such choice, because Apple imposes a ban on other browser engines.
TFW you tell regulators you need to prevent real competition “because privacy and security”[…]
[…]
Some of us are salty about this because:
- our engines don’t have this problem
- our products on iOS do have this problem
- Apple won’t let us keep our users safe
Safari 15 IndexedDB Leaks (Hacker News):
The demo illustrates how any website can learn a visitor's recent and current browsing activity (websites visited in different tabs or windows) using this leak. For visitors, logged into Google services, this demo can also leak Google User IDs and profile pictures.
Previously:
Update (2022-01-19): Nick Heer:
You know what is most wild about this for me? I came across this bug when working on some web development last autumn, but I assumed I must be misinterpreting what I was seeing because there was no way such a critical vulnerability would be so transparently visible.
Update (2022-01-25): Juli Clover:
With the macOS Monterey 12.2 and iOS 15.3 release candidates now available, we could see these updates be made available to the public as soon as next week.
8 Comments RSS · Twitter
>TFW you tell regulators you need to prevent real competition “because privacy and security”[…]
This argument is flawed. You can be restrictive in the name of privacy and security and still have bugs in those areas. Or, to put that differently: there's a difference between having privacy weaknesses out of self-interest, and having inadvertent privacy weaknesses.
@Sören In this case, it’s an inadvertent weakness made worse by self-interest (Apple’s desire for a monoculture it controls). Apple’s argument was that other engines have flaws that WebKit doesn’t, so they shouldn’t be allowed. If that’s to be taken seriously, you have to count the opposite cases, too.
Does Apple have anyone left in their QA department?
TFW when enforced single point of failure, in combination with institutional neglect is exploited.
"This argument is flawed. You can be restrictive in the name of privacy and security and still have bugs in those areas"
That's not what people are arguing, though, as far as I can tell. What people are saying is that, by preventing competition, Apple creates a situation where literally any bug of theirs immediately allows their whole user base to be exploited, without any recourse or mitigation until Apple fixes the problem, and deploys the solution to everybody.
So yeah, you're right, "you can still have bugs in those areas." But that's not an argument in Apple's favor, that's an argument against their entire approach.
@Kristoffer Yes, and it seems like this bug was ignored until 2 months later when it began circulating on social media.
@ Michael, Plume: fair.
My other issue with the reporting is that it's only been 52 days, well below responsible disclosure standards (e.g., Google Project Zero's 90 days). It is absolutely an issue, but I've seen arguments that Apple "wouldn't have bothered to fix this" if not for FingerprintJS's disclosure, and we don't really know that.
I'm still dragging my heels on iOS 14, and will continue to do so for a while longer...wearing a wry smile.