This announcement makes me wonder - Are there any banking laws to protect someone who loses money due to a hack?<p>The JS thing is a huge deal so someone might get their online banking credentials stolen and then account emptied. In which case, how helpful are the banks in helping to recover the money?<p>On the cryptocurrency side people need to secure their own money and ensure they don't open some shady ICO site. So stolen credentials means the money is gone forever.<p>Edit: FDIC insurance is applicable for the banks ie if the banks get hacked. The question here is on individuals getting hacked. I am not able to find if FDIC covers that.
[related] Has anyone considered the possibility of a Spectre-style attack in Ethereum's Turing-complete EVM? Not that the state would be unique for all contracts, but there's a possibility of communicating to an external contract with the output.
A notably worthy response while others aren't handling it so well. It's nowhere close to being Coinbase's fault, but they are far in front the matter. Kudos.
I think this is a foreshadow of what's to come with quantum computers. While side channel attacks aren't directly related to quantum computing, they're of a similar character. Quantum computing will enable new kinds of analysis that aren't possible to do quickly right now, and exploits based on it will very likely take people by surprise in the same way that this one has... even those of us who saw it coming. It will be a weird, unsettling feeling when these classical cryptography algorithms, which everyone trusts so casually right now, start actually being compromised.
>Where we do run on shared hardware, we make it more difficult to accurately target one of our systems by rapidly cycling through instances in AWS.<p>Wait, doesn't that just spray their sensitive information over more and more machines that may or may not be sufficiently wiped before it's reassigned to someone else? Or increase the chance they encounter someone running one of these exploits panning for digital gold in the other users RAM?
Knowing Coinbase uses AWS, they were my main concern: <a href="https://news.ycombinator.com/item?id=16066221" rel="nofollow">https://news.ycombinator.com/item?id=16066221</a><p>They answered fast.
I really appreciate how coinbase is addressing this like Chase has sent nothing about this, coinbase in contrast is telling you how they handle transactions to minimize the potential damage and what they are doing to mitigate the issues on their end. Big thumbs up to coinbase for being aggressively and open about their response to this threat.
Don't think this is right on one detail.<p>Spectre2 should allow malicious JavaScript to read data from other processes.<p>Running browser tabs in separate processes (e.g. Google Chrome's new Site Isolation) should protect data from Spectre1 alone but not Spectre2.<p>See the table here:<p><a href="https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html" rel="nofollow">https://security.googleblog.com/2018/01/more-details-about-m...</a><p>If that's not right I'd love to be corrected.<p>Probably no known exploit of this yet.
> Coinbase runs in Amazon Web Services (AWS) and our general security posture is one of extreme caution.<p>Now more than ever, this statement just does not compute. What good reason could something as sensitive as Coinbase have to remain on a third-party cloud provider and let Amazon hold the keys to the kingdom, especially after this disclosure that informs us that our imagined VM sandboxes have been a fairy tale all along?<p>There's a secret from a time not so long past that makes these attacks nearly-irrelevant: "don't run untrusted code". Maybe the corollary "don't run on hardware that runs untrusted code" is necessary (though I personally feel it's a little redundant).<p>It's embarrassing that Coinbase would continue to expose their application to this attack surface after yesterday's disclosures. Honestly, it should've been that way before; this isn't the first time VM isolation has been broken, and it won't be the last. It's just the least-fixable breakage so far.<p>> Sensitive workloads, especially where key handling is involved, run on Dedicated Instances (instead of shared hardware). Where we do run on shared hardware, we make it more difficult to accurately target one of our systems by rapidly cycling through instances in AWS.<p>I'm quoting this just because I know people will say I'm excluding the context if I don't. If you're going to run on "dedicated instances" anyway and pay the huge price premium for them, there's no reason to continue to put your secrets in Amazon's hands.<p>Little ragtag startups may use the excuse "We're scared of real sysadmins, they will laugh at us because they're over 25", but that excuse should not work for something as big and serious as Coinbase.<p>Playing Instance Roulette by "rapid cycling [instances]" in hopes that you get away from any bad neighbors ASAP is extremely silly, <i>please</i> give me a break. Just buy some hardware. How is this so hard?
It's a good thing no one will be running other people's untrusted code on their servers ..... Except for etherium contracts of course .... Anyone want to place bets on how long it takes before someone releases a spectre exploit in a contract? I'll take 4 days ....