[HN Gopher] Spook: Side channel attack which could read the memo...
___________________________________________________________________
Spook: Side channel attack which could read the memory from
Password Managers
Author : dcu
Score : 196 points
Date : 2021-09-22 16:11 UTC (6 hours ago)
(HTM) web link (www.spookjs.com)
(TXT) w3m dump (www.spookjs.com)
| Aachen wrote:
| Damn, I thought this must be a Dutch find since Spook.js lends
| itself beautifully as a Dutch word, but alas.
| the-dude wrote:
| The English meaning is much more appropriate.
| _wldu wrote:
| 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...
| i80and wrote:
| > 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
| dotancohen wrote:
| 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.
| DaiPlusPlus wrote:
| 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
| sigg3 wrote:
| 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
| bananaportfolio wrote:
| 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.
| gzer0 wrote:
| 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.
| theogravity wrote:
| This is around the third time that I've read about a
| vulnerability with LastPass.
|
| Is 1Password susceptible to the same attack?
| joshAg wrote:
| 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.
| [deleted]
| pseudosavant wrote:
| 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.
| floober wrote:
| 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.
| MrWiffles wrote:
| As if we needed yet another reason to avoid Chrome and friends...
| RcouF1uZ4gsC wrote:
| 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.
| jack_pp wrote:
| 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.
| bee_rider wrote:
| That's just security by obscurity.
| unethical_ban wrote:
| 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.
| bee_rider wrote:
| 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.
| dotancohen wrote:
| Security by obscurity keeps my SSH logs clean. Not many
| bots come knocking on port 22122 (not the real port).
| eropple wrote:
| "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.
| latchkey wrote:
| 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.
| manbart wrote:
| No sr g. It on we fbeg feed th C hey Vic
| bee_rider wrote:
| 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.
| sroussey wrote:
| 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.
| webstrand wrote:
| You might be thinking of the Public Suffix List?
| https://publicsuffix.org/
|
| Though, that one doesn't include tumblr.
| jasonshaev wrote:
| >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.
| kobalsky wrote:
| > 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)
| Groxx wrote:
| 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_.
| IncRnd wrote:
| 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.
| bee_rider wrote:
| Perhaps there's a preexisting template for "dramatic spectre-
| related security announcement website" that has that part of
| the FAQ pre-populated.
| tedunangst wrote:
| 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.
| [deleted]
| c7DJTLrn wrote:
| Alright, it has a site and a logo, it checks out.
| bjt wrote:
| 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.
| alanbernstein wrote:
| 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?
| somehnacct3757 wrote:
| 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.
| Fnoord wrote:
| I was using Windows Terminal the other day and it does not
| copy text after selection. Ended up pasting a password
| instead...
| bee_rider wrote:
| I think the only solution here is to not use an OS designed
| from the ground up by surveillance capitalists.
| Rd6n6 wrote:
| 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)
| BugsJustFindMe wrote:
| By default your computer and mobile phone OS and browsers
| likely let webpages and apps read your system clipboard without
| asking permission first.
| jonnycomputer wrote:
| Most desktop/laptop browsers don't provide clipboard read
| access without asking permission first. Mobile is another
| thing tho.
| alanbernstein wrote:
| Keepass can clear the clipboard after pasting.
| neandrake wrote:
| 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.
| jayknight wrote:
| 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).
| dotancohen wrote:
| 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.
| loudtieblahblah wrote:
| IMHO - keepass was way faster via keybinding than dragging
| your mouse to a browser plugin drop down.
| jackson1442 wrote:
| 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.
| outworlder wrote:
| Your clipboard has a huge attack surface.
| UI_at_80x24 wrote:
| 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.
| kam wrote:
| 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.
| ziml77 wrote:
| 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.
| marbu wrote:
| Good mitigation of that would be for a password manager to
| store an url along with password.
| K5EiS wrote:
| That is usually what password managers do.
| Biganon wrote:
| 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)
| marbu wrote:
| 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.
| the8472 wrote:
| 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.
| orangepurple wrote:
| You paste the HTTPS login URL from your password manager
| entry THEN log into the page after the browser validates the
| HTTPS certificate
| barbazoo wrote:
| One would argue that then you're way beyond "microseconds
| of lost productivity".
| IncRnd wrote:
| 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.
| tedunangst wrote:
| Millions and millions of microseconds lost.
| loudtieblahblah wrote:
| 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.
| infogulch wrote:
| > 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.
| stnmtn wrote:
| 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!
| orangepurple wrote:
| I have used KeepassXC for almost a decade and never used
| that title matching feature.
|
| Control-U all the way
| unethical_ban wrote:
| 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.
| infogulch wrote:
| 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.
| unethical_ban wrote:
| 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.
| csnweb wrote:
| 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.
| hirvi74 wrote:
| 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.
___________________________________________________________________
(page generated 2021-09-22 23:00 UTC)