Project Zero is very well known for things exactly like this. Partially, it's because they are incredibly talented, but there are also talented people in academia and in other security consultancies. The biggest difference with Project Zero is that their primary [0] goal is altruistic: find vulnerabilities, and let people who can fix them know (vs publishing papers, securing paying clients, auctioning zero-days, etc), in the interests of making the internet and computing as a whole a safer place.

[0] Their secondary goals are to protect Google products and services, and to provide excellent PR in line with what we're discussing right here.

Worth noting that in this case, many of the authors are in academia. It wasn't solely a Google project.

I read it as it was an independent discovery by project zero and by academia researchers.

Independent discovery don't happen overnight. Intel must have been aware of these vulnerabilities for some time.

edit: I'm sure everyone involved acted responsibly. I'm just curious as how far apart these independent discoveries were made.

The bug has been around forever, but it must have been discovered relatively recently since it's not fixed in hardware yet.

I've always been baffled by the concept of simultaneous discovery.

The Spectre paper includes this line in the acknowledgements:

> We would like to thank Intel for their professional handling of this issue through communicating a clear timeline and connecting all involved researchers.

So Google people and the Germans were working on the same thing without knowing of each other until Intel connected them?

Graz is in Austria, but considering these things are usually kept quiet quite long: probably yes

Google project zero blog says: We reported this issue to Intel, AMD and ARM on 2017-06-01

We talked about NSA and how people are leaving for greener pastures. Wondered two things:

1) Have any of them ended up in Project Zero or working on stuff like this

2) Wonder if NSA knew about this vulnerability and now someone there in a windowless office is sighing saying to themselves "Welp, another backdoor we can't use".

>their primary [0] goal is altruistic: ... making the internet and computing as a whole a safer place.

Which is, at the same time, highly rational: to secure their entire market.

It's nice to have big corp's incentives aligned with the public good. Too bad it happens so rarely.

Hm that's tricky. These awesome findings didn't exactly provide net value for google, not even on the not so short term (next 10 years?). They've created a large problem for Google! :-)

Yes and no. The cost of some malicious party figuring it out and using it on Google would potentially been far greater than anything this could cost.

How much value would be destroyed if black hats discovered the bug first and people started discovering that information from their Google cloud VMs was getting leaked?

Sure, Google could just patch themselves, but the information to recreate the issue would surely be leaked by a xoogler, since it only takes a single sentence describing the vuln for a competent sec team to recreate it

Discovering a vulnerability is not creating it. A vulnerability exists even if it was not publicly disclosed. There were probably other people already exploiting it.

Imagine the law suit if Google fails to detect this....

Suppose you have transportaion company that owns 80% of the market share for everything transported on the roads. By car, van, truck, semi, everything.

Suppose your company also has a team that inspects public bridges to make sure they don't collapse.

Is it really altruistic, or given your market share is it a cost of business?

Oh, come on. Their only goal is to make Google money. The fact that they do useful work is a nice side effect, but if they didn't improve Google's security and give good PR there's not a chance in Hell Google would keep them around.

I don't know how you would evaluate such a thing as "best security team," but Project Zero certainly attracts a high calibre of security expert. If you're into breaking things, why wouldn't you want to break things with other bright people and the support of a massive corporation?

How about based on how many of the serious issues are found by Google. It has been one after another.

They're definitely world class, but they're also loud about it. Consider that other teams perhaps have a different model. For instance, Microsoft's internal team surely finds lots of clever bugs that never get talked about in Microsoft products.

I assume the NSA finds and quietly stockpiles some very clever vulnerabilities, too.

I can't imagine better marketing for cloud services than making it as clear as you can that the world is a very dangerous place for computers and if you don't have a crack team of hundreds of battle-hardened security engineers then you have no business hooking your computers up to the internet.

The irony here is that a good ol' dedicated hardware web server is far less susceptible to Meltdown or Spectre than Google Cloud, because only your code is running on the CPUs.

I predict tonight's disclosures will lead to an uptick in interest in running websites on dedicated hardware, like we did back at the turn of the century.

> Spectre

Spectre doesn't really care if it is cloud or bare metal. They are equally vulnerable unless disconnected from internet.

To get you with Spectre, the attacker must be able to run code on your CPU.

This affects browsers with Javascript enabled because your Javascript engine runs foreign code on the CPU. The bad guy puts nasty code in a page, you visit the page, the code executes on your machine--boom.

And it affects public cloud web servers because multiple cloud servers (virtual machines) run on one CPU. So some attacker might be able to jump out of their VM and read your VM's memory.

BUT, on a dedicated hardware web server, there shouldn't be any foreign code running--no foreign VMs, and no browser.

There are many dedicated servers that are shared across users or clients and were expected to be isolated.

Any user who has access to a system (developers or support or sysadmin) has the ability to read arbitrary memory. The vulnerability can probably be leveraged to privilege escalation or bypass the isolation.

Spectre doesn't let u do cross VM memory reading, Meltdown does, AFAIK. If you want to read other VMs memory, u need to RUN in those VMs yourself and within the right process.

So cloud instance and bare metal ones are equally vulnerable under Spectre: as long as they can transfer their malicious code to your VMs and runs it. Can't really see how bare metal servers mitigate this problem.

Pretty hard to have a neighbor vm execute Spectre on your same physical server if you have dedicated hardware.

Add in that Spectre specifically is a js bug so in order to be vulnerable your server would need to execute untrusted JavaScript and I think we can assume the threat surface of this specific bug is smaller outside the cloud...

Pretty sure that its not limited to js:

https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9...

Its a technique, not a flaw in js, from my understanding

This PoC is implemented in js, but my point stands regardless of the language used. It requires code executing on the same physical server as your app in order to be an issue for you. Similar to a hypervisor escape (since we're being pedantic yes, I understand this is not a hypervisor escape), the evil neighbor surface is not present if you have no neighbors.

I don't think you understand the bug here.

1) https://spectreattack.com/: "Spectre tricks other applications into accessing arbitrary locations in their memory. " Spectre does not let you execute code in another guest

2) Spectre is not javascript specific. I am not sure why you think it is, beyond the fact a PoC was written in js

I don't think you understand my point. You should reread my post, especially the first sentence. It's first and alone for a reason; not sharing hardware is an effective mitigation against vulnerabilities in shared hardware.

Obviously it's not just a js bug, there are other PoCs in other languages.

I never said anything about executing code in another guest, not sure where you got that from.

>Pretty hard to have a neighbor vm execute Spectre on your same physical server if you have dedicated hardware.

You have no reason to care about a neighbor VM executing Spectre on the same physical server, since they're only hurting themselves, not you.

>Add in that Spectre specifically is a js bug so in order to be vulnerable your server would need to execute untrusted JavaScript and I think we can assume the threat surface of this specific bug is smaller outside the cloud...

"Spectre specifically is a js bug"

Spectre is exploitable from processes, not just containers.... containers are equivalent to processes from it's point-of-view as the kernel is shared.

So... you may be able to go native to avoid having neighbours, but this does not prevent other processes exploiting your process. To do that you need to prevent any downloadable code from running.

This of course is possible and is the entire reason why the ARM document explains that most embedded systems are not affected due to the fact that they will not download and execute code (of any form).

Hmm, or maybe it's a reason to go with bare-metal providers :)

If true, how are edge computers going to connect to the cloud?

Chromebooks, obv. Integrated marketing strategy!

Also Android

Cloud services will benefit from this greatly.

Spectre occurs no matter you are in cloud or not, while cloud companies can advertise themselves to help customers proactively to mitigate such risks.

Did you forget the Technical University of Graz students who came up with rowhammer and KAISER in the first hand?

Not really, they are mentioned in the article. What is fascinating is the number of discoveries by the Google team. The Wikipedia page has a summary of the prominent ones: https://en.wikipedia.org/wiki/Project_Zero_(Google) these are not bugs in obscure pieces of software but on major services and operating systems.

Come on, Google completely "forgets" to mention the others, whilst the others do mention Google who detected it independently. And then look who wrote the papers, exploits and patches.

> Come on, Google completely "forgets" to mention the others

Err… fourth paragraph:

> Before the issues described here were publicly disclosed, Daniel Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also reported them; their [writeups/blogposts/paper drafts] are at: Spectre (variants 1 and 2) Meltdown (variant 3)

Yuval Yarom's contribution (Flush+Reload) seems quite understated, considering how important it is to the attack.

I wonder how much of it relates to their mastery in data science.

I keep wondering if they got some “””AI””” fuzzer that helps them a ton? Plus tons of compute power to spend (remember SHA-256 clash they found “just because”?)

No collision has been found in SHA-256. SHA-1 is the broken hash function