Spook: Side channel attack which could read the memory from password managers | Hacker News Reader

Spook: Side channel attack which could read the memory from password managers

spookjs.com

295 pointsdcu87 comments

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.

> 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.

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.

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.

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

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.

It looks like they were able to exploit the Last Level Cache of Intel and Apple processors, but failed to do so against an AMD processor using the Zen architecture. Instead of plainly saying as much, the authors simulate a theoretical leakage rate for AMD processors by way of making V8 expose clflush in absence of a practical LLC eviction mechanism.

Tangentially related, but is my understanding of the V8 expose clflush instruction correct?

AMD introduced the Clflush instruction which was supposed to decrease the number of TLB misses and improve performance. This instruction was ultimately responsible for making V8’s behavior erratic and unpredictable with regards to memory operations.

Modern processors with x86-64 architecture support 2-way page tables and most modern operating systems support several layers of virtual memory. However, many of these techniques made the V8's behavior unreliable and unpredictable which led to a performance hit for AMD processors with AMD chips especially those who implemented TLB remapping instructions.

So does this justify my use of a password manager with no browser integration, and all the microseconds of lost productivity due to copying and pasting passwords all the time?

Pasting a password into a phishing site because you don't have the browser checking the domain for you seems like a bigger risk than being exploited by something like this.

Agreed. The only time I nearly lost an account to phishing it was because I manually copy-pasted my credentials. It's an easy mistake to make, especially if you happen to be tired or distracted.

You paste the HTTPS login URL from your password manager entry THEN log into the page after the browser validates the HTTPS certificate

One would argue that then you're way beyond "microseconds of lost productivity".

I have a wrapper script for pass (passwordstore.org) named pass-open that selects a password file using fzf, copies the included password and opens the included URL (if there is one). Also, my password files may include web browser names and profile names because I log into sites using different web browsers and profiles.

So in addition to being my password manager, pass and my wrapper script are my cross-browser bookmark manager, which is convenient because I'm usually in a terminal emulator.

I've never understood why people at HN use graphical password managers that are integrated into web browsers and autofill, etc. (but I've never understood why people at HN use most of the graphical software they use).

You’re not crazy, but we are in the minority.

Most people, self-professed hackers included, are more comfortable in the browser sandbox than the terminal emulator sandbox.

pass has a better UX than any password manager I’ve ever been compelled to use for work. Especially when used in the way you describe, as your index to the browser (rather than as a sidecar to the browser).

That's what I do for certain types of sites, such as bill-payments, and I don't lose any productivity. It does take time, yes, but there isn't enough time lost that would inhibit productivity.

By around 6 orders of magnitute :-)

Millions and millions of microseconds lost.

Good mitigation of that would be for a password manager to store an url along with password.

Parent comment was precisely using this as a pro for in-browser password managers (or extensions). They can check the current domain. A standalone desktop app can't do that (well it can, but it's a bit more complicated to truly understand what tab you're currently looking at, and intend to use a password with)

To clarify: I suggested to store url in the password manager so that when I want to login somewhere, I go the the manager, locate the account, copy paste url stored there into url bar of the browser in a new tab, and then do the same with actual credentials. There is no room for any phishing in such case.

That said I understand that when a password manager is closely integrated with (or even within) a browser, it can do more checking for me, and make the whole experience nicer. But such integration is imho not a silver bullet, and there are downsides which comes with this approach as well.

That is usually what password managers do.

If you're not using SSO/central identity providers and use each site's own login form instead you're much less likely to encounter an unexpected login form which makes any such form suspicious.

The classic phishing is an email from e.g. Facebook saying your account is at risk of something. So you click the Facebook link and sign in to Facebook (uh oh that was actually a phishing site pretending to be Facebook). I don't see how avoiding SSO helps with this.

Email is a separate topic. I have a domain and use a separate address for each service. So phishing tends to go to the wrong address and thus the wrong folder, which makes things pretty obvious.

My point is I don't see how whether you use SSO or not is relevant. If you use SSO, you could fall for an SSO phishing page. If you don't use SSO you could fall for a non-SSO phishing page.

If your email is hidden, then someone might send you a phishing link via a HN reply. The reply might link to a website that has a domain similar to Facebook and presents a Facebook phishing login.

My experience with SSO workflows is that they often ask for reauthentication due to limited credential timeouts. They pop up randomly as you visit sites you're used to visit.

On the other hand site-specific logins tend to last longer which means I'm unlikely to encounter a login prompt as part of regular browsing.

To given an example, github only prompts me for my personal credentials when I use the security settings or to authorize a bot. This doesn't happen often, so it's somewhat surprising and makes me check. But my $WORK SSO tied to their github org (and a whole bunch of other things) wants me to log in every other day. This makes more less likely to check since it's forced routine.

>But my $WORK SSO tied to their github org (and a whole bunch of other things) wants me to log in every other day.

I don't think consumer SSO does that. I think Facebook and Google generally try to avoid logging users out randomly because it causes user annoyance as well as user loss (because a lot of users might not remember their passwords or bother logging back in again).

Your work SSO can tolerate a bad user experience in order to have higher security. You're being paid to log in every day. Facebook and Google users aren't being paid to log in every day, so many of them won't.

I used to use KeePassX (and KeePassXC) for over a decade and I know a lot of people hate it because it doesn't have online syncing and you have to go out of your way to use yet another app to get it to integrate into a browser.

But one of the wonderful things it does over every other password manager is Auto-Fill based on a keybinding.

It would look at the Window Title and find the available passwords that matched. This was infinitely more useful than most browser-plugins that look at URL within the browser.

Because now I could have it fill out auth for Windows shares.

If a website has a .htaccess User/Pass window - most browser plugins wont autofill this, but KeePassX(C) could.

Terminal? I had all my SSH Passphrased and Sudo passwords in KeepassX(C) and could auto-fill on keybinding.

It was wonderful.

After failing to backup my database a few times and losing portions of newly added passwords I finally threw in the towel and went with Bitwarden.

and bitwarden checks a lot of boxes - open source, you can self-host if you wish, third party audits, a good use of encryption, cross-platform both for browsers and desktop/mobile OSes.

but man do i miss just autofilling with a keypress and not reaching for the mouse and autofilling in places outside of the browser.

Anyways, I mention this b/c it's way better than manually copying/pasting. The Auto-fill would work by tossing it to the clipboard just long enough to do the auto-fill and then clearing the clipboard. So it was safer than manual copy/paste too.

> It would look at the Window Title and find the available passwords that matched.

Ew that sounds awful for security and ripe for phishing. Nothing stops a site from setting the title to whatever they want, at least with a browser extension it only shows credentials when the domain matches, giving you a chance to second-guess it.

Seriously, if I own faceboook.com and I just set my title to Facebook, this would copy in my facebook password? Sounds really really bad!

I have used KeepassXC for almost a decade and never used that title matching feature.

Control-U all the way

I think it's great that you use it in a way that protects you by always starting your workflow from your password manager and copying the URL into your browser. But I think it's important to recognize that 1. this requires extra steps, and 2. this represents a drastic change in workflow for the vast majority of users. Your solution will not work for most people.

It doesn't automatically fill it in by landing on the page. It can detect how to autofill, and what password to use, based on window title.

Your scenario still depends on the person landing on a phishing site and choosing to attempt a login.

I think the distinction you're trying to make means zilch, 1. this is the normal login flow for these users, 2. this tech provides zero protection from phishing attacks, 3. an extension does provide protection from phishing attacks by automatically comparing the saved domain vs the page's domain byte-for-byte on every visit and not suggesting a login if the actual domain doesn't match, 4. humans have empirically proven that they cannot do 3 reliably. There is a first hand experience of this fact in this very thread: "The only time I nearly lost an account to phishing it was because I manually copy-pasted my credentials.".

"choosing to attempt to login" is just bare-faced whitewashing in order to blame the user for falling prey to a phishing attack and deny that this is a problem that password managers should solve.

Ah, see that's where I didn't understand you.

I did not make the assumption that my offline password manager should integrate with my web browser to provide phishing protection. That's not a bad idea! I'm not denying it's something password managers could solve. I just don't rely on it.

Interesting, I've been using KeePassX(C) for over a decade too. I store the .kbdx file in a Dropbox folder and can access it from other devices. Never ran into issues with this setup.

At least in the bitwarden chrome extension you can autofill with a keyboard shortcut (and I assume in the ones for other browsers too). On mac os it defaults to CMD+shift+L. But that obviously doesn't work outside of the browser. Still might be interested for you.

I've had an awful time getting this to work consistently. Same with the prompting to add/update a new entry upon creating/changing a password.

KeePass can emulate a keyboard and type your credentials for you. But it's initiated from the KeePass app instead of requesting it from the browser. It is slower than just having it autofilled but faster than copying it to your clipboard (where other programs might have access to it).

My muscle memory copies the URL from the browser into the Keepass search bar. Thus, I get more-or-less protection from rogue URLs as well - and I'm forced to look at the URL with my eyeballs.

IMHO - keepass was way faster via keybinding than dragging your mouse to a browser plugin drop down.

Not sure what other managers you’ve used but with 1Password I just press cmd+shift+x to show a popover, arrow keys to choose the account, then press enter. No mouse needed.

For anyone looking for a personal password manager that is not a browser extension but also provides the functionality to auto-type passwords into the focused field I highly recommend codebook

https://www.zetetic.net/codebook/

It's a one-time fee (per device~ish) and you can connect & sync it to Google Drive, Dropbox, Local folder, or to another device over WiFi. I've been using it for a few years and it has great iPhone and macOS integration. The Windows integration is also good but not quite as smooth as being integrated with FaceID or thumb print ID.

Yes, but a much better argument against doing that:

If you keep your passwords separate from your browser then you are guaranteed to be safe from a browser exploit.

By default your computer and mobile phone OS and browsers likely let webpages and apps read your system clipboard without asking permission first.

Most desktop/laptop browsers don't provide clipboard read access without asking permission first. Mobile is another thing tho.

Keepass can clear the clipboard after pasting.

Your clipboard has a huge attack surface.

I'm paranoid about putting a password into the clipboard. Some OS's keep a clipboard history or some users have software that does this.

Another worry is that some app ecosystems provide a way to read my clipboard over their permission model. With this permission in hand, surveillance capitalists will include it as part of their fingerprinting techniques. So even if you trust those platforms, you also have to trust the packet headed their way and what they do with it.

With Linux/KDE desktop and KeePassXC, the password manager removes the copied text from the clipboard and the clipboard history after a short (configurable) delay.

I was using Windows Terminal the other day and it does not copy text after selection. Ended up pasting a password instead...

I think the only solution here is to not use an OS designed from the ground up by surveillance capitalists.

That’s hard if your job depends on access to a windows only program like photoshop or a game engine (unity and unreal editors technically work on Linux, but it’s really painful)

Web browsers today have “everything but the kitchen sink” capabilities built-in and are becoming more and more complex each year. They are turning into whole platforms that have browser plug-ins and extensions for every possible need known to humankind.

While many of these add-ons are handy and useful, we should not trust them with password management. Browsers are just too complex and have far too much going on.

Full article: https://www.go350.com/posts/the-design-flaws-of-password-man...

> Web browsers today have “everything but the kitchen sink” capabilities built-in and are becoming more and more complex each year.

Thinking back to the Netscape Suite and Mozilla, this is a fun cycle

Yes, but that was application capabilities, not platform capabilities: back with Netscape Communicator there was no insanely-capable JavaScript features like WebUSB, WebRTC, TypedArray buffers, and so on. This is what we're referring to when we say web-browsers are like operating-systems: because of the capabilities afforded to JavaScript programs, not because the browser is bundled with a built-in mail client (like Emacs...) or because of non-web-platform feature bloat like Seamonkey.

---------

I imagine eventually Thunderbird will come back as a 100% JS application (no more XUL?) in a normal Firefox (or Chrome, or Edge, or Safari, but not iOS Safari, because reasons) window - making use of a hypothetical-but-easily-imaginable WebIMAP, WebPOP, or just after raw TCP sockets become a thing in JS: https://wicg.github.io/raw-sockets/docs/explainer.html

Actually, Chrome today is a great Javascript IDE and application runtime. There's Chrome extensions for everything from calculators to full CRMs.

I'm just waiting for it to get a decent web browser.

Alright, it has a site and a logo, it checks out.

I guess security researchers feel compelled to do this career-wise. It's not enough to just report a CVE. You need a marketing site for your exploit to get it picked up in the tech press and establish your reputation. Starting to feel like academics chasing citations.

Given my struggles explaining Spectre to some professional developers having a logo and a name seems like a smart idea if you want to convince someone who doesn't program at all to listen to you at all.

As if we needed yet another reason to avoid Chrome and friends…

I believe Chrome goes much further than Firefox in trying to isolate websites into separate processes. If anything, I would guess that Firefox would be much more vulnerable to these kinds of attacks.

From the FAQ on the page:

We have tested Spook.js on Chromium, which is the basis of the Chrome browser. Thus, in addition to Chrome itself, we expect most Chromium-based browsers to be vulnerable to some variant of Spook.js. This includes recent versions of Microsoft's Edge browser, as well as Brave which is a privacy-centered browser.

Other browsers like Firefox and Safari use very different JavaScript execution engines, which currently stops Spook.js from working. We leave the task of investigating speculative exection attacks on these browsers to future work. Finally, Firefox has recently introduced Strict Site Isolation in its stable release. While Spook.js does not work on Firefox as is, we note that similarly to Chrome, Firefox also consolidates pages based on their eTLD+1 domain.

It might be the case that Firefox is less vulnerable in general because it is not as targeted even though technically it might have more undiscovered exploits.

That's just security by obscurity.

"Security by obscurity" is a phrase frequently repeated but generally misunderstood. There is value in not having the lock everybody's trying to pick with very advanced attacks so long as it is generally proof against being kicked down by simpler ones.

So, sure, it may be security-by-obscurity--but it can also be significant and helpful depending on one's threat model. "Security by obscurity" is not a disqualifying objection under most models.

Security by obscurity keeps my SSH logs clean. Not many bots come knocking on port 22122 (not the real port).

Not only is that not always a bad thing, but your statement implies that (a) it is the fault of FF that it is "obscure" for the purposes of security, and (b) that they aren't secure in the traditional sense, and only rely on the obscurity portion.

I think the comment I responded implies that, more than mine. I'm writing this in Firefox, and I suspect that it is probably actually more secure in some nebulous sense just because they don't have any need to comply with shady characters like Google. But the particular advantage highlighted doesn't seem so great.

This is why I use the 1Password Classic extension (which they try to deprecate in favour of 1Password X).

If I understand correctly, this extension can only ever ask the main 1Password UI (running in its own system process) to appear (providing site metadata such as the URL so it can suggest relevant accounts), in which I can then select the password I want. This means the browser extension itself has no access to the master password nor the entire password database.

In contrast, 1Password X and LastPass seem to let the browser extension access all passwords including the master password.

And other than Chrome?

> we expect most Chromium-based browsers to be vulnerable [... including] recent versions of Microsoft's Edge browser, as well as Brave

Some of these claims... "can retrieve data from Chrome extensions (such as credential managers) if a user installs a malicous extension."

News flash, you can do pretty much anything you want if you can get the user to install a malicious extension. That is social engineering, not a side-channel attack.

I think the severity of this would very much depend on the permissions that would have to be granted to the extension in order for it to happen.

This is around the third time that I've read about a vulnerability with LastPass.

Is 1Password susceptible to the same attack?

it's not anything specific to lastpass, because it's an issue with how chrome was(n't) isolating extensions. That's just the pw manager extension they picked for proof of exploitability. Any password manager that has a chrome extension that prefills passwords has the same issue.

Will putting `rel=noreferrer` on your links help you protect from this?

No sr g. It on we fbeg feed th C hey Vic

Damn, I thought this must be a Dutch find since Spook.js lends itself beautifully as a Dutch word, but alas.

The English meaning is much more appropriate.

Reply on news.ycombinator.com