Hacker News Reader

Comment by bee_rider | Hacker News Reader

This title seems a bit over-broad. The attack is based on using the built-in chrome credential manager. Further, it seems to depend either on the user installing an evil chrome plugin (in which case, you are already doomed, right?), or confusing a website like Tumblr into mixing up the user content and the login page, and getting the autofill info there.

The second attack seems limited to just the site that is being messed with. The fact that sites like Tumblr which apparently (?) host random unvetted javascript for bloggers aren't protected by site isolation is not that surprising, right?

Anyway, autofill and built-in password managers have always seemed suspicious to me. People should stick to stuff like keepass I guess.

View on HN

> This title seems a bit over-broad. The attack is based on using the built-in chrome credential manager

I'm reading the white paper[and from what I understand the password manager attack is just a sample.

The vulnerability exposes data from other tabs that get consolidated on the same process, so it doesn't matter if it came from the password manager or if you typed it, it's grabbing it either way.

They even managed to leak an image uploaded on a different tab. (page 13, figure 14 https://www.spookjs.com/files/spook-js.pdf)

Page as a whole seems over-broad. E.g. the first FAQ entry:

> Have I been affected by this attack?

> If you have an Intel processor or an Apple device with the M1 chip, then yes with very high probability. We also expect our attack to be effective for AMD machines, however this has been only partially demonstrated.

while also further down

> Has Spook.js been abused in the wild?

> We do not have any evidence so far that Spook.js has been or not been abused in the wild.

and I haven't been able to find any references whatsoever to evidence that this technique has been actively used.

Perhaps there's a preexisting template for "dramatic spectre-related security announcement website" that has that part of the FAQ pre-populated.

Yea. They are calling both the vulnerability and the exploit as "the attack", but they are wrong.

I'll just take a moment to point out that the article requires js for the FAQ. It may use JS for other areas I am unaware.

Pretty much...

> Have I been affected by the polonium sushi attack?

> If you have a digestive tract, then yes with very high probability. We also expect our attack to be effective against those fed via IV, but this has only been partially demonstrated.

Older UGC site makers have this issue when posting such sites as subdomains. Newer ones put user stuff on subdomains of another top level domain. Mitigations include having login on a separate domain and use oauth to yourself. :)

There is actually a list of such sites that Firefox has (had? haven’t been in the space in a while) that they could use for various reasons. Like treating the tumblr.com domain as an international domain (co.uk) which Google search would do as well.

You might be thinking of the Public Suffix List? https://publicsuffix.org/

Though, that one doesn't include tumblr.

That might explain this issue being found on Tumblr…

Thanks for the link!

>We show that despite Google's attempts to mitigate Spectre by deploying Strict Site Isolation, information extraction via malicious JavaScript code is still possible in some cases.

The allusion to Spectre seems odd to me too. This really has nothing to do with Spectre, other than it (sort of?) being a side-channel attack. So Google's Spectre mitigation not "fixing" this isn't surprising.

Google describes the strict site isolation as "Site Isolation is a large change to Chrome's architecture that limits each renderer process to documents from a single site" And they developed that largely in response to Spectre.

What the paper did was related to the site isolation, and not Spectre, but there was a lineage there...Spectre -> Site Isolation -> This Side Channel attack still works.

They showed that while Google said "single site", they really meant "same tld, but hostnames can differ" and "if you have control over a page on b.whatever.com, you can artificially gain side-channel visibility to c.whatever.com" via window.open() or iframes and some memory pressure.

Seems fairly significant given that many sites have user generated content on a.example.com and more important/sensitive stuff on b.example.com.

> They showed that while Google said "single site", they really meant "same tld, but hostnames can differ"

That is how "site" has been defined in the web world (compare to "origin").

For example, consider the SameSite attribute on cookies, site is also used there to mean same tld different hostname. So its not like google made a slip. They've been using this nomenclature consistently.

How is the second attack limited? They use the malicious extension to recover the LastPass master password.

Reply on news.ycombinator.com