Update on Meltdown and Spectre | Hacker News Reader

Update on Meltdown and Spectre

engineering.coinbase.com

209 pointsjorde100 comments

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.

Would the FDIC cover losses?

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

For regular consumers, the FDIC insures up to $250k IIRC.

Insurance companies usually try to reduce/manage risk.

Does the FDIC have security / computer / process requirements for the banks which they insure against hacks?

I think that would be part of the FFIEC https://www.ffiec.gov

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.

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

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.

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.

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.

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

Completely. These are banks we're talking about, not bitcoin exchanges.

well when the account is emptied, the money will be going places. Seems like a similar scenario to someone stealing your credit card.

Federal Reserve Regulation E covers bank account fraud. See page 13 of this PDF: https://www.federalreserve.gov/boarddocs/supmanual/cch/efta....

Basically your fraud protection involves your responsibility to notify the bank, and the bank's responsibility to refund the money if you notified them in time. Check your statement or balance at least once every 60 days and report fraud immediately, and you can't lose more than $500.

Fraud and theft are not covered by FDIC insurance. FDIC insurance protects your balance, up to a limit, if the bank fails or if there is a run on the bank.

OK, so that sounds like it would work out well in the case of ordinary fraud. You notify the bank in timely fashion, and the bank covers it.

But in the case of the bank being hacked, I could imagine it affecting enough accounts that the bank cannot cover it. Would that count as the bank failing (or perhaps a run on the bank?), and so then be covered by FDIC insurance?

Finally, suppose the hack is a case of financial terrorism. Say, a state sponsored group is trying to undermine confidence in the banking system and so wants to be as disruptive as possible. Instead of just getting in and stealing some money, they have been in for months and have been sabotaging things. They mucked with the backup procedure to make it so the backups are corrupt, and the bank unwisely did not do actual restore tests on samples to check things. Finally, the hackers set everyone's account balance to zero (or more fun, delete everyone's account).

So now my bank has no idea how much money I'm supposed to have (or even if I'm a customer). They fail and FDIC steps in. Do the banks have to periodically give the FDIC or other regulators lists of accounts and balances, so that FDIC would be able to at least figure out things up to the last month, say, or would the FDIC also have no idea who gets what?

A few words as a sysadmin:

* offsite backups

* verified offsite backups (not saying this happens everywhere but I'd expect banks to some kind of routines)

A few words as a news reading citizen:

* force majeure

* fannie mae and freddie mac

> verified off-site backups

So important... i can’t tell you how many times I’ve come across a database backup process that either the cron had been failing for months, that wasnt backing up all the data, or was simply corrupted.

Not only verify your backups, but make sure you know you’re restore process too!

You’ve got to trust that our banking systems do this thoroughly though ... amirite?!1!!

These things depend on jurisdiction and your particular contract, but in the western world generally some things apply:

  * transactions are printed physically (iirc SEPA mandates this) (account balances can be recovered, like bitcoin)
  * accounts are insured up to some ammount (will be covered by insurer provided bank cannot cover)
  * bank will cancel/refund transactions that happen x hours prior to proper notification of account compromise (details vary)

>>> So now my bank has no idea how much money I'm supposed to have (or even if I'm a customer). They fail and FDIC steps in. Do the banks have to periodically give the FDIC or other regulators lists of accounts and balances, so that FDIC would be able to at least figure out things up to the last month, say, or would the FDIC also have no idea who gets what?

When a was running an exchange, which is far from a bank but already has annoying scrutiny.

We were required to have a feed of all the transactions to an off site location. Then we had to store off line archives and off site archives.

The location must be within the jurisdiction of the regulator so they can send the police to the datacenter, seize all the hardware and reconstitute the balances.

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

There's a twitter thread where some cryptographers speculate on the possibility. The upshot is that it doesn't seem like it will be possible:

https://twitter.com/bascule/status/948725249842937857

From my understanding there are a couple things that probably make this a non-issue:

1) Worst case scenario, it only allow you to read the memory of systems running validator nodes. There aren't very many of these (tens of thousands perhaps) and they generally don't store particularly valuable secrets. A small number of them may store private keys to Eth accounts with a small amount of Eth, but that's not typical operating procedure.

2) The EVM doesn't have any internal mechanism for measuring time (beyond existing blocks), so any timing attack within the EVM would require some very clever way of measuring time.

In the Spectre paper they note that while Chrome degrades the resolution of `performance.now()`, they were able to get a timer with sufficient resolution by using a Web Worker (thread) which repeatedly decrements a value in shared memory. As far as I know the EVM intentionally doesn't provide any concurrency because execution must be deterministic, and it seems doubtful that any kind of message-passing from outside the contract would be fast enough to provide the resolution needed.

However, the block-lattice cryptos like RaiBlocks that find a way to build in concurrency and shared memory might be different.

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.

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

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.

Quantom computers are going to be much "slower" in terms of becoming a problem. We just had the public disclosure of Meltdown and Spectre, and I suspect that, with what is known publicly, a non trivial amount of CS undergrads would be able to successfully craft an exploit based on this.

In contrast, even if we suddenly solved the engineering challanges of building a large quantum computer, it would likely take a while for the economics to work out where a quantum based attack would be economical. For one, for the foreseable future, quantom computers would be expensive (needing high cooling at a minimum), so a 'casual' attacker would need to wait for an economical rental type service to emerge. Also, it would take time to scale up production, so the first bunch of quantum computers will be expensive due to market pressures from big players.

In reality, it is likely that quantom computers would see a gradual (even if exponential) rise in power that would give some idea of a timeline for when we have to adapt. Not to mention the research into replacing quatom vulnerable crypto with quantom resistent crypto for over a decade, and has already led to (seemingly) quantom resistent replacements.

This is an interesting perspective. It reminds me of waking up one day and watching a video of boston dynamics' atlas sticking a backflip. Yes, these things have been in development for decades, but there's something very startling about when you suddenly realize how much they've matured.

Only because you aren't an expert and aren't aware of the state of the art in the field. Spookiness has no correlation with actual threat.

Even for experts, classical and quantum computing both involve very complex engineering. There are inevitably going to be hurdles and growing pains. This moment feels like a growing pain...

I'm imagining that the transition to quantum computing will come with growing pains of similar magnitude.

It's like when you turn the hot water on and run it over your hand. At first it's cold, gradually it gets warmer and warmer, then there's a moment when you pull your hand out... the water is suddenly too hot, it's crossed a threshold.

> It reminds me of waking up one day and watching a video of boston dynamics' atlas sticking a backflip.

Save you some googling in case you wanted to see that:

https://www.youtube.com/watch?v=knoOXBLFQ-s

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

A practical quantum computer would be capable of breaking almost all modern public key cryptography.

There's an entire field of research dedicated to figuring out what we'll replace those algorithms with if quantum computing does become practical on a significant scale: https://en.wikipedia.org/wiki/Post-quantum_cryptography

Specter and Meltdown have nothing to do with cryptography

Most side-channel attacks have mainly been a threat to the implementation of cryptographic systems and algorithms. Now Specter and Meltdown have brought that concern to all systems.

The gist of the parent post is, create complex systems and these things will bite.

"Anything I don't understand is a threat."

Yes. Something you don't know about can and may well kill you. These are the lessons of geography, astronomy, and physics. Crypto and computer security may well have the same properties.

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.

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.

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

It's definitely a possibility (not sure how likely though).

"In the comments section of the Antonoupolos’s talk, reddit user @cfromknecht explains that there are flaws to the Elliptic Curve Digital Signature Algorithm (ECDSA), and it is very possible that quantum computers will be able to work faster than the transactions, therefore beating the encryption. “Whenever you spend bitcoins, you must include a signature that approves the spend, which is done using ECDSA” they explain, “If these signatures can be broken faster than transactions can be confirmed, an attacker could sign a different transaction that spends your coins before the original transaction is ever accepted.”

https://edgylabs.com/quantum-computing-hacking-blockchain

If anything, I'm invoking the mystery of mathematics. Here is a list of unsolved problems in mathematics:

https://en.wikipedia.org/wiki/List_of_unsolved_problems_in_m...

Seriously though, I'm talking about something qualitative here. When I read about these side-channel attacks yesterday I had this crazy gut feeling about how exposed our technologies are to those who learn to understand them deeply.

There's an complementary kind of arrogance to the one you're suggested: "anything I don't understand couldn't possibly be a threat... since I could never easily exploit it, it'd be way too hard for someone else to."

But have you listened to the radiolab about the z-cash cryptography ritual? It's very enjoyable and has a spooky surprise ending:

http://www.radiolab.org/story/ceremony/

I think I see where you are coming from and had, I think, a similar feeling.

This class of attack sits in that “uncanny valley” of:

1) possibly easy to spot when looked for in the right way [edit: to use the QC analogy: search for classical algorithms which are easily broken]

2) totally systemic across almost all currently deployed technology

is that what you mean?

Yes, definitely, that's the kind of thing I'm thinking about, especially #2. Whereas a lot of exploits are happening with updateable software, it's rare that hardware gets hit so hard. This stuff hit on a deeper level.

I hope I don't offend anyone too badly here with this medical analogy, but it's like finding out you have a bad flu vs. finding out you have Parkinson's.

Or, it's like seeing someone in a different light for the first time... maybe you've known them for decades, but all of the sudden, you see them in this completely different way.

I am baffled. What does quantum computing have to do with the topic of this thread - Meltdown/Spectre attack?

Please provide specific details as others have said - this comment just sounds like you just had something vaguely related to security that you wanted to mention.

macawfish speculated (pun intended) that "they're of a similar character" and I see his point. They're classes of attacks that are well known, have a huge impact, but still feel like they take us by surprise.

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

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

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

And what happens to that RAM when an instance is terminated. Is it zeroed or does the data linger until it is later overwritten by another process? Or maybe that's what you're referring to?

I'd hope that Amazon would zero out that RAM first, since whoever uses the machine next could always dump /dev/mem.

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

---

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

You know an IP doesn't necessarily mean a single machine instance, right?

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.

Knowing Coinbase uses AWS, they were my main concern: https://news.ycombinator.com/item?id=16066221

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.

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

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

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.

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.

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

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

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.

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.

Perhaps they could also be as attentive at sending their customers their money.

Take a gander at http://reddit.com/r/coinbase and weep...

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

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

Probably no known exploit of this yet.

That's a pretty serious detail. Does that mean someone could read the clipboard?

I think so.

But I'm just inferring that from Google's security blog posting; I can't say with real expertise.

Would love for an expert to chime in.

Disclaimer: I'm not a CPU designer or a kernel developer so I'm not sure I've grokked this yet, but I think I did. Someone who knows, please correct me if I'm wrong.

My understanding is that Spectre will allow an attacker to read any memory anywhere in userspace, so yes, that would include the clipboard. Meltdown is just an enhancement to Spectre that allows it to also read into kernel space (ring 0). Spectre is the systemic issue that accurately deduces memory values based on CPU cache heat. Meltdown is the implementation-specific issue, which affects many ARM SKUs and virtually all Intel SKUs, that makes privileged memory susceptible to the same.

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

Thanks for weighing in.

Speaking as a layman:

Running on the same physical core is a pretty common case on laptops.

Sharing a library with your target is probably a very common case. For instance, libc.

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

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

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

Friendly reminder to disable Javascript, at the very least, by default.

Only run Javascript on domains you really need and trust, and even then the minimum amount required for the site to function.

https://github.com/gorhill/uMatrix/

> Only run Javascript on domains you really need and trust, and even then the minimum amount required for the site to function.

This is so inconvenient that practically no one is going to do it. I used to use NoScript but found I was just constantly clicking "temporarily allow."

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

Obscurity does provide additional security.

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

Rotate, Repave, and Repair “Its idea is quite simple. Rotate datacenter credentials every few minutes or hours. Repave every server and application in the datacenter every few hours from a known good state. Repair vulnerable operating systems and application stacks consistently within hours of patch availability. Faster is safer.” https://builttoadapt.io/the-three-r-s-of-enterprise-security...

When you reboot your EC2 instance, that VM is provisioned on a (patched) system.

Yes, they would have been better off leaving out this "cycling" bit altogether.

Perhaps proving that you're running on the same hardware as Coinbase is most easily done by statistical attacks, which requires collecting data over time.

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

The same way issuing a new session token for each login improves security. If the changes are unpredictable, whatever process an attacker uses to guess the correct target must be restarted every time the target changes.

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

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

Those who trust Amazon with all of their secrets don't like to be told that they shouldn't be doing it.

Do you think just “any kind of FS” running things on their own is patched or firmware updated before embargo lifted, etc? Or is even informed pre-disclosure?

How is that an issue if they're not multi-tenant anyway? It's not like Amazon will go in and automatically patch your guest image whenever there's a security problem. This is only an "advantage" when you're running on a cloud and the issue affects the underlying host, in which case, there's even more reason not to be in the cloud, because it's just a reminder "any of these thousands of strangers we've stuck you with could've been breaking the isolation this whole time, gee sorry about that".

It's not that there are never security issues on non-cloud systems, but the risk of cloud is severely underappreciated. I don't know how anyone can claim otherwise in a post-Specre world. At least on non-cloud, you don't have to worry about the CPU stabbing you in the back.

Spectre can read data out of memory at hundreds of kilobytes per second. That's plenty fast to get interesting data out of Coinbase even if they're "rapidly cycling" their instances. And really that just means you just have to camp out and wait for them to come to you, rather than trying really hard to get on the same instance as them, which would probably be harder. You just have to know what region + az they're in (not secret), and you can probably guesstimate some other stuff and end up on a similar hardware class, and then I am sure that after not-too-long they'll join your host.

And sure, Spectre is now "mitigated" as far as we know, but it wasn't until recently, so we don't know who could've done this, and it's not like that's the only VM isolation breaker out there. There are certainly more conventional bugs that are readily exploited. There are also other non-technical attack vectors on a provider like AWS, like Amazon employees.

I may be more understanding if there was some important reason to take these kinds of risks, but honestly it's ridiculous that people cling to the cloud so desperately. Hardware is not that scary and a lot of hardware jockeys are pretty friendly. Is software really so age-discriminatory that no one remembers a life before cloud servers? It wasn't that bad!

Call your local hardware vendor and they'd be ecstatic to set you up with a rack running VMWare or Xen or whatever "private cloud", giving you the convenience of a hypervisor without the risk profile of sharing a CPU with every Tom Dick or Harry on the internet.

And the real kicker? It'll be 10x cheaper than the annual AWS bill for comparable resources.

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

Noone has been running their own datacenter for a while.

> Noone has been running their own datacenter for a while.

I tend to agree that new businesses are very unlikely to invest in their own metal - because it's not really a path to profitability, but many small-medium businesses run their own data centers. Especially if the business was founded in the 90s and the leadership hasn't chosen to invest in tech.

Many businesses choose not to scale (in ways which cloud services would help) - many more just have no need to scale (i.e. regional service providers).

Big difference between running on colo'd hardware and running on cloud. It's still "own hardware" in someone else's rack.

The hardware can be leased. It doesn't have to be yours.

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.

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.

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

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

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.

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

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

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

Reply on news.ycombinator.com