
Update on Meltdown and Spectre - jorde
https://engineering.coinbase.com/update-on-meltdown-and-spectre-45d344c47b5
======
thisisit
This announcement makes me wonder - Are there any banking laws to protect
someone who loses money due to a hack?

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?

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.

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.

~~~
a_cactus
Money in banks is FDIC insured. I believe that protects it from things like
hacks, even if the bank itself went bankrupt.

~~~
twblalock
FDIC insurance doesn't cover theft or fraud. It covers your balance (up to a
limit) if the bank fails. There are separate regulations for fraud.

~~~
taejo
But presumably it does cover your balance if the bank fails because it can't
cover a large loss to fraud?

~~~
Xylakant
The loss in case of fraud against the customer or losses due to a hacked
customer is entirely the customer loss. The bank does not care, they don't
have any loss. Spectre is an attack against the client and the customer is
responsible to keep his client secure. It's not the banks device, they have no
power over it.

~~~
jonknee
That's not how it works though, people get hacked all the time and banks make
their customers whole. You can literally leave your debit card on the street
corner and you won't be liable for any fraudulent charges as long as you
notify the bank of them.

~~~
Xylakant
Not in Europe in general. Chip and PIN leads to the assumption that you made
the purchase or initiated the charge. In any case, card charges (or charges in
general) are something entirely different than payments initiated from your
banking client. Anyone can charge your account and you can dispute the charge.
However, money sent from your account cannot actively be disputed. You can
tell your bank that you accidentally transferred money and they’ll try and
stop the transaction, by if it goes through, you need to retrieve the money
from the person that got it. Banks will try to help in case of fraud as long
as the money is in their reach, but will not make you whole at their expense.

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

~~~
techman9
Does the Ethereum VM have branch prediction or speculative execution. I'm not
sure how you'd construct a side channel of this nature against it if it
doesn't.

~~~
TazeTSchnitzel
The VM just needs branches, it's the host CPU's prediction you're messing
with.

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

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

~~~
soberhoff
What are you talking about? Without further details I'm under the impression
that you're just invoking the mystery of quantum computing. "Anything I don't
understand is a threat."

~~~
gizmo686
Much of modern crypto is based on the assumption that integer factorization
and discrete logarithms are difficult problems. With quantum computers, this
is known not to be the case.

~~~
jpatokal
Known not to be the case _if_ they actually worked in real life, that is.
We're still waiting for a solid demonstration of quantum supremacy to prove
that though.

~~~
mmaurizi
Yes. And we were waiting on an attack that used speculative CPU execution /
branch prediction since 2006.

------
dukeflukem
Possibly off topic, but is this a bad time to use any software that knows your
cryptocurrency private keys. Such as wallet software?

~~~
dredmorbius
Or, say, ssh-agent, going beyond crypotocurrency.

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

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?

~~~
wqerqwerqwe
Data for coinbase.com

sam.ns.cloudflare.com sue.ns.cloudflare.com

A direct-connect IP address was found: coinbase.com 107.21.102.138 UNITED
STATES

Previous lookups for this domain:

2015-04-28: coinbase.com 107.21.102.138 UNITED STATES

2015-02-28: coinbase.com 54.243.122.18 UNITED STATES

[http://www.crimeflare.us/cgi-bin/cfsearch.cgi](http://www.crimeflare.us/cgi-
bin/cfsearch.cgi)

\---

They've also used the same EC2 IP address for 3 years, so the claim is
bullshit.

~~~
mdeeks
It is probably an ELB that fronts multiple VMs that they cycle through. Also,
that is only their website. I'm sure they have more infrastructure than just
the VMs that host their web app. It is quite easy to have a single unchanging
IP address and constantly rotating instances behind it.

------
wslh
Knowing Coinbase uses AWS, they were my main concern:
[https://news.ycombinator.com/item?id=16066221](https://news.ycombinator.com/item?id=16066221)

They answered fast.

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

~~~
jonknee
... Perhaps because your money at Chase is safe regardless of the bug.

~~~
SippinLean
Can you elaborate on how this differs from Coinbase? My understanding is that
they are insured. If you are a US customer your cash balance at Coinbase is
insured by the FDIC (like it is on Chase).

~~~
jonknee
If someone gets into your Coinbase account and transfers everything to their
wallet there is no recourse and you're out all your money. If someone gets
into your Chase account and transfers all your money out there is a recourse
and you get all your money back.

Essentially if Coinbase loses all your USD it should be covered under the
FDIC, but if Coinbase loses all your BTC there's nothing you can do.

~~~
SippinLean
Right, a strength and weakness of cryptocurrency is that you are your own
bank.

This post was mostly about what Coinbase is doing to mitigate the risk in
their architecture (like AWS) I thought you were implying that Chase's
vulnerabilites were different in some regard.

>If someone gets into your Chase account and transfers all your money out
there is a recourse and you get all your money back

There is? My understanding is that fraud and theft are not covered by FDIC
insurance.

~~~
jonknee
> There is? My understanding is that fraud and theft are not covered by FDIC
> insurance.

It's covered by the bank themselves. You might have to wait a little bit, but
you won't be held liable for fraudulent charges. I'm sure there are horror
stories, but the vast majority of cases result in someone other than you
eating the loss.

Needing help from the FDIC is sort of a worst case scenario for banking, it's
extremely uncommon unless there's a 2009 style banking crisis.

~~~
SippinLean
Ah then Coinbase is the same in that regard. Chase has the opposite strength
and weakness regarding theft: you must rely on them.

~~~
jonknee
No, it's not the same. If someone spends your BTC there is no recourse and
it's gone forever. Coinbase specifically does not insure against this.

~~~
SippinLean
I meant only that the subject of the article, Coinbase's architecture's
vulnerability was the same as Chase's, instead of "your money at Chase is safe
regardless of the bug."

You are correct, as they mention in the first paragraph of the article you are
responsible for securing your own machine and wallet.

Your USD is insured and covered by the FDIC at Coinbase and Chase. Theft is
not covered by the FDIC at either.

------
javert
Don't think this is right on one detail.

Spectre2 should allow malicious JavaScript to read data from other processes.

Running browser tabs in separate processes (e.g. Google Chrome's new Site
Isolation) should protect data from Spectre1 alone but not Spectre2.

See the table here:

[https://security.googleblog.com/2018/01/more-details-
about-m...](https://security.googleblog.com/2018/01/more-details-about-
mitigations-for-cpu_4.html)

If that's not right I'd love to be corrected.

Probably no known exploit of this yet.

~~~
philip_coinbase
(blog author here) It's unclear but I doubt it is practical given the
preconditions required in the Spectre paper. see
[https://spectreattack.com/spectre.pdf](https://spectreattack.com/spectre.pdf),
section 5 for the details of Spectre2 (aka branch target injection).
Successful exploitation depends on the ability to predict the location of a
useful gadget in target process memory and impact is limited to processes
running on the same physical core. It also requires a branch mis-prediction
training period which seems to be _significantly_ easier to execute if you're
running as an application and share a library with your target. Not saying it
is impossible, but the bar to success seems way, way higher than with
Spectre1.

~~~
gesman
>> Let us know by filing a ticket ...

Last few tickets I filed with Coinbase took days/weeks/never to get a
response. Others seems to have a similar experience:
[https://www.reddit.com/r/Bitcoin/comments/735yqe/how_do_you_...](https://www.reddit.com/r/Bitcoin/comments/735yqe/how_do_you_get_coinbase_to_respond_to_a_support/)

>> However, there are a few actions you should take right now to limit your
exposure ...

None of the actions suggested includes the action of keeping cryptocurrency in
user's own deterministic wallet to avoid _any_ exposure from Coinbase side.

~~~
goldenkey
Coinbase is such a giant scam. Insider trading...questionable banning of
users..the list goes on. Doing business with the devil is never pleasant!

------
matthewaveryusa
How does cycling AWS instances quickly provide additional security beyond
obscurity?

~~~
sanxiyn
Obscurity does provide additional security.

~~~
MichaelApproved
They aren’t trying to obscure, they’re trying to be a moving target.

------
cookiecaper
> Coinbase runs in Amazon Web Services (AWS) and our general security posture
> is one of extreme caution.

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?

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

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.

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

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.

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.

Playing Instance Roulette by "rapid cycling [instances]" in hopes that you get
away from any bad neighbors ASAP is extremely silly, _please_ give me a break.
Just buy some hardware. How is this so hard?

~~~
hellbanner
Not sure why you're being downvoted. Running any kind of financial service I
would expect a corp to run their own hardware.

~~~
user5994461
Truth is, they will outsource to Equinix or specialized datacenters.

Noone has been running their own datacenter for a while.

~~~
MandieD
Most very large old-school industrial firms still own and run a lot of iron
on-prem, especially in data-privacy focused places like Germany. My employer,
one of those old-school German industrial firms, is just starting to dip its
little toes into the cloud - everything important is still on-prem. Companies
are _talking in public_ about their cool cloud stuff, but talking to my fellow
OSGIF engineers, we're all really in the Proof of Concept phase, pretty much.

~~~
user5994461
on premise has been on the decline for almost two decades. It didn't wait for
the buzz around AWS.

Try outsourcing a software project to some sweatshops, they will offer you to
rent the hardware in their datacenters. Germany is no exception.

------
DennisAleynikov
Glad to see coinbase communicating proactively to assess their own risk
factors and let them be known

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

~~~
dbancajas
Evm is a stack based machine with no speculative execution. It has no concept
of a process. I find it impossible to think how spectre can be implemented.

~~~
Taniwha
the machine is still implemented with machine code, it might even be JIT'd ...
after all people have used spectre from JS

~~~
gm-conspiracy
It is my understanding that JS provides a higher resolution of temporal
comparison, which makes the exploit possible.

------
grover_hartmann
I won't take anything Coinbase says seriously until they implement SegWit.

