It's a developing story, but from the information we have so far, it does look like Intel involving AMD is a disingenuous since AMD processors are not affected by the most serious of the issues.
It's too early to say which is ultimately the most real-world serious.
From the Spectre note (which does affect AMD):
In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it.
How quickly are we going to see attacks targeting BTC/ETH wallets, apps etc. on clients and cloud hosted exchanges?
To be fair, the Intel post alludes to collaborating with AMD/ARM on mitigating Spectre, but userspace memory leaking is wholly separate from kernel memory leaking (Meltdown, which only affects Intel processors).
There aren't really any special Android ARM CPUs, maybe they are confident it doesn't really work on Android because it's very difficult to get the timing precision and low-level assembly sequences in Java/ART compiled code. Though I wonder how that squares up with JNI.
I think the key to the statement is in any case that you need to differentiate between what is possible on the processor architecture level when you have full software control, and what is possible on an operating system level, where 3rd party applications are further restricted in various arbitrary ways such as only allowed to use Java, limited access to high resolution timing primitives, etc. that can make practical exploitation impossible, even if the flaw is present.
It's difficult to reason about because it's hard to tell if you can manipulate a JIT runtime into generating the code you need for the exploit to work - and as the JavaScript implementations show, the answer is often "yes".
JIT engines (and compilers) often generate a familiar instruction patterns. Many JIT engines Target specific languages (like JS) and as result have "simpler" optimizers (less time to do this) and possibly more stable instruction patterns. So my money is on somebody fuzzing the required JS code.
We know that the scariest attack "meltdown", cannot be reproduced on AMD or ARM chips at all[1]. The second attack "Spectre" is also greatly mitigated due the neural network predicting pathways for the application. Thus it's unlikely/less-likely that you'll be able to access other locations in memory[2]. However, it's definitely possible.
Yes, from my understanding, Spectre is an architectural-level flaw in the so-called speculative execution unit. In other words, Spectre will only be fixed once Intel, AMD, and ARM redesign the unit and release new processors. Given the timelines of CPU design, this will take 5-10 years at least.
On the positive side, the flaw is very difficult to exploit in a practical setting.
> On the positive side, the flaw is very difficult to exploit in a practical setting.
Is it?
"As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs"
There are possible mitigations for cloud providers:
1) pay $x / hour and run on shared machine with possibility of an attack;
2) pay $y / hour (where x < y) and run all your processeses on dedicated machines without anybody else.
Moreover the option 2) already exists for large customers and security sensitive applications (e.g. CIA dedicated cloud built by Amazon).
Amazon instances can be created with the dedicated flag. The host hardware will be dedicated to you, not shared with any other users. It should mitigate the attack.
The flag has a fixed fee in the thousands of dollars and each instance is 10% more expensive.
After reading that thread, I sort of wonder if this is the catalyst for the next tech bust. Prices on the basic building block of the modern tech industry (a server shard) going up 30%, or even more as shared/virtual services must be decommissioned for isolation? Surely it’s an alarmist thing to think and I don’t think it’s likely, but if you asked me yesterday the likeihood of an underlying security vulnerability effecting every processor since 1995 I’d have said probably not.
Major props to the teams working on this... now time for us all to hold onto our pants as we ask for budget increases that will make shareholders demand blood.
The only sorts of companies where server costs could increase hugely due to a sudden need for hardware isolation are those where they're running tiny or incredibly bursty workloads. Big companies like Netflix that use tons of cores can just binpack their work all together on the same hardware so their jobs only share hardware with other jobs controlled by the same company. Effectively, cloud providers will start offering sub-clouds into which only your own jobs will be scheduled.
This is actually how cloud tech has worked for many years internally. I worked at Google for a long time and their cluster control system (Borg) had a concept called "allocs" which were basically scheduling sub-domains. You could schedule an alloc to reserve some resources, and then schedule jobs into the alloc which would share those resources. Allocs were often used to avoid performance-related interference from shared jobs, e.g. when a batch job kept hogging the CPU caches and slowing down latency sensitive servers. I suppose these days VMs and containers do a similar job, though I think the Borg approach was nicer and more efficient.
I guess this sort of per-firm isolation will become common and most companies costs won't change a huge amount. The people it'll hit will be small mom-and-pop personal servers, but they're unlikely to care about side channel attacks anyway. So I wouldn't sell stock in cloud providers just yet.
I can't really see how it would be fixable even with new hardware.
Speculative execution is fundamental to getting decent performance out of a CPU. Without it you should probably divide your performance expectations by 5 at least.
Rolling back all state rather than just user visible state in the CPU is neigh on impossible. When you evict something from the cache, you delete it. Undeleting is hard. There are also a lot of other non-user-visible bits of state in a CPU.
Couldn't you do something like have a separate chunk of "speculative cache" which you only commit to the main cache once the speculatively-executed instructions are retired? Sounds complex, sure - but it seems like that would give you the performance benefits of speculative execution while still being able to roll back (or prevent in the first place) any cache-state side effects when branches were mispredicted. Could also imagine processors start segregating cache by privilege level.
I guess part of the question you're raising is: are there so many different caches, translation buffers, etc. in a modern CPU that keeping 'uncommitted buffers' for the state of all of them would be just as complex as throwing a whole other core in there?
No, that would not be enough. CPUs speculatively execute across multiple branches. Even if you had a separate speculative cache for every code path, you could still build a side-channel from the amount of contention. [1]
> Both hardware thread systems (SMT and TMT) expose contention within the execution core. In SMT, the threads effectively compete in real time for access to functional units, the L1 cache, and speculation resources (such as the BTB). This is similar to the real-time sharing that occurs between separate cores, but includes all levels of the architecture. [...] SMT has been exploited in known attacks (Sections 4.2.1 and 4.3.1)
I agree that we'll probably see new attacks in this area for a long time.
That said, the main new ingredient of Spectre seems to be the idea that userspace can poison the branch target buffer to cause speculative execution of arbitrary code in kernel space. That part of the attack should be fairly easy to mitigate with new hardware, by XORing (or hashing) the index into the BTB with a configurable value that depends on the privilege level. So each process has its own "nonce", and they're all different from the kernel's.
Then BTB poisoning won't work unless the attacker knows its own and the other context's nonce. Even if further attacks are found that leak this nonce, they could be mitigated by changing the nonce at regular intervals.
It effectively means wiping the caches, TLBs, BTBs and any other caches and optimisations on any form of context switch, as far as I can see? Which yes will likely require new silicon.
As far as I know they HAVE to register a trade in advance. I.E. three months ahead: "I will sell 600 shares on 15th of December if the share price is above 50". This information is public and other people can use this information before the trade actually happens.
Even a low-power core like a Cortex-M7 can do some speculative execution through its branch predictor.
Though of course a M7 isn't running VMs, and probably isn't running any kind of attacker-controlled code (scripting included - its there, but rare), so many of the vectors aren't present.
Then front-runs the negotiated timeline anyway, catching projects like Xen off guard (it seems like)[0]. Will be interested to read the postmortem of the entire process from start to finish, and Xen is promising one from their perspective. I'd be especially interested to understand whether public intel was concrete enough to rush this out the door, because it didn't seem like it was, but I probably missed something.
speculation was apparently hitting very close to home allowing attackers with resources (think nation states) to start developing their own tooling. at least this early announcement allows people with sensitive data to quickly move to dedicated instances.
edit: well it didn't take a nation state after all: https://twitter.com/brainsmoke/status/948561799875502080 - given that, you can be sure that everybody who counts is frantically launching these on your clouds gathering whatever they can.
I reimplemented variant 3 based solely on clues from twitter posts yesterday.
I am by no means a computer security guru - I just did a CPU architecture course at uni and figured I'd cowboy up an implementation. It worked nearly first time, and can read both kernel and userspace pages from userspace by fooling the branch predictor into going down the wrong path, and relying on the permission checks to be slower than the data reads from a virtually addressed cache. It can only access stuff already cached though, so you can't do a full memory dump with it.
Not exactly; it says "we are unaware of any successful reproduction of this vulnerability that would allow unauthorized information disclosure on ARM-based Android devices."
I like the way you say moment as if the android kernel is some single thing not a hodgepodge of hundreds of different kernels across tens of companies.
> During the course of our research, we developed the following proofs of concept (PoCs):
> A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.
> A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]
> A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.)
> A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache.
If I'm reading this right, then the only POC that works against ARM is the first one, which lets you read data within the same process. Not too impressive. (Yes, I know that I'm reading into this that they tried to run all the POCs against all the processors. But the "Tested Processors" section lower down leads me to believe that they did in fact do so.)
The third and fourth POC seem to be Intel-specific.
The paper from the other people who discovered this says the same thing: "We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage
to successfully leak kernel memory with the attack de-
scribed in Section 5, neither on ARM nor on AMD." The general purpose attack that leaks kernel memory, the one that KAISER fixes, only seems to work on Intel CPUs. Intel's press release was misleading.
Well... reading further, below the details of the third POC, they say "Our research was relatively Haswell-centric so far. It would be interesting to see details e.g. on how the branch prediction of other modern processors works and how well it can be attacked."
So it seems like they tried it on AMD and ARM, but they tried much harder on Intel. That's less reassuring than my initial reading.
"AMD chips are affected by some but not all of the vulnerabilities. AMD said that there is a "near zero risk to AMD processors at this time." British chipmaker ARM told news site Axios prior to this report that some of its processors, including its Cortex-A chips, are affected."
"Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.
Which systems are affected by Spectre?
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors."
Not just user memory reads. AMD CPUs won’t speculate loads from userland code directly to kernel memory, ignoring privilege checks (“Meltdown”). But they are still subject to the “Spectre” attack, which can disclose kernel memory by taking advantage of certain code patterns (which normally would be harmless) in kernel code.
But that means the root user or someone with root effective privs or CAP_* to load programs into a kernel interpreter or kernel JIT. If you've given someone permission to do this from a user process you've probably opened up to more mundane issues. I suspect this is why AMD says the issue is near zero, if you've given away the keys to the kernel you're already in trouble.
AMD's ASID blocks the issues for VM guests (and root users on VM guests).
For variant 1, a kernel JIT is definitely helpful, which is why the Project Zero PoC used it, but it's not required.
For variant 2, Project Zero used the eBPF interpreter as a gadget, a fake branch destination, without having to actually create an eBPF program or use the normal userland-facing eBPF APIs at all. And they only chose it as the least "annoying" option (see quote below).
edit: I'm not sure how ASID support would mitigate either of those variants, though there may be something I'm not thinking of. (It would help with variant 3, but that's the variant AMD wasn't vulnerable to in the first place.)
quote:
> At this point, it would normally be necessary to locate gadgets in the host kernel code that can be used to actually leak data by reading from an attacker-controlled location, shifting and masking the result appropriately and then using the result of that as offset to an attacker-controlled address for a load. But piecing gadgets together and figuring out which ones work in a speculation context seems annoying. So instead, we decided to use the eBPF interpreter, which is built into the host kernel - while there is no legitimate way to invoke it from inside a VM, the presence of the code in the host kernel's text section is sufficient to make it usable for the attack, just like with ordinary ROP gadgets.
I should clarify I mean user to root privilege escalation.
I totally understand how the breaking out of the javascript sandbox attack works and the fact that IPT won't help with that. With Linux's clone(), you could clone without CLONE_VM and use CLONE_NEWUSER|SYSVMSEM and then unmap everything except the Javascript interpreter / JIT and leave a shared memory map and communicate only via the shared memory map and SYSV semaphores for synchronisation. Obviously this wouldn't be available on other platforms.
By "user to root privilege escalation", I'll assume you mean leaking kernel data without root, since this attack doesn't directly allow escalating privileges at all.
For variant 1, you would need to find some legitimate kernel code, accessible by syscall, that looks at least somewhat similar to the example in the Project Zero blog post:
if (untrusted_offset_from_caller < arr1->length) {
unsigned char value = arr1->data[untrusted_offset_from_caller];
unsigned long index2 = ((value&1)*0x100)+0x200;
if (index2 < arr2->length) {
unsigned char value2 = arr2->data[index2];
}
}
In practice, you may not be able to find something nice like "((value&1)*0x100)+0x200", but even if it simply used 'value' as an index, you would be able to at least narrow it down to a range. Other code patterns may work too (and potentially be more powerful?), e.g. conditional branches based on 'value'.
For variant 2, see caf's answer to you in another thread.
>>> By "user to root privilege escalation", I'll assume you mean leaking kernel data without root, since this attack doesn't directly allow escalating privileges at all.
The attack allows to read all the memory. Isn't there a way to scan for passwords or ssh keys and turn that into a privilege escalation?
Sure, SSH keys would probably work on a system with SSH enabled; I just wouldn't count that as "directly". (That would include most servers but exclude most Android devices; I have no idea whether there are other escalation methods for Android.)
Direct or indirect is meaningless at this point. The exploit is proven, they just have to determine the "best" memory locations to read to make something "useful" out of it. Then it's bundled together as an exploit kit and it's Armageddon.
To make it a bit clearer how this works: the Variant 2 exploit poisons the branch target buffer to cause the processor's speculative execution in kernel space to jump to an entirely attacker-controlled destination when it hits a branch that matches the information the attacker has placed into the BTB. The actual retired instructions don't go this way of course - the processor detects the misprediction and goes back to execute the real code path - but the speculatively executed path still leaves evidence behind in the caches.
They test how a series of branches are predicted after returning from a hypercall, which lets them basically dump out the state of the BTB. From that, and knowledge of where the branches are in the hypervisor binary (the binaries themselves aren't really a secret, only the relocated load address is) they can figure out the load address of the hypervisor.
See the section "Reading host memory from a KVM guest / Locating the host kernel". It's terribly clever.
Their particular exploit for variant 1, which uses eBPF, only worked on AMD with the eBPF JIT, i.e. it did not work with the eBPF interpreter. But there are many other potential avenues to exploit that variant which have nothing to do with BPF. The result does suggest that it may generally be harder to trigger variant 1 on AMD processors (because they doesn't speculate as much?), but harder ≠ impossible.
Do you need root or comparable privileges to take advantage of BPF? I did not think that was the case. My understanding was that BPF code executes within the kernel.
BPF is employed by the `bpf()` syscall for socket packet filtering, as well as by `seccomp` itself for its syscall filtering. Is this threat vector not available to untrusted processes?
iirc I think that the BPF JIT is disabled by default? Your kernel might be compiled with `CONFIG_BPF_JIT`, but I think the sysctl knob (`bpf_jit_enable`) is set to 0 by default.
Also there's a sysctl for unprivileged BPF called `unprivileged_bpf_disabled`. On my system it seems to default to 0.
That article links a commit [1] that contradicts this statement
> AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.
And Axios [2] that Zdnet quotes gave a comment from AMD:
> "To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time. We expect the security research to be published later today and will provide further updates at that time."
And a comment from ARM:
> Please note that our Cortex-M processors, which are pervasive in low-power, connected IoT devices, are not impacted.
My read is that vulnerable processors generally have to:
1. Have out of order execution
2. Have aggressive speculative memory load / caching behavior
3. Be able to speculatively cache memory not owned by the current process (either kernel or otherwise)
4. Have deterministic ways of triggering a speculative load / read to the same memory location
2 is probably the saving grace in ARM / low power land, given they don't have the power budget to trade speculative loads for performance (in the event they're even out of order in the first place).
Caveat: I'm drinking pretty strong Belgian beer while reading through these papers.
How does that pertain to the vulnerabilities that involve eBPF? My understanding is that eBPF code executes within the kernel, and so would run at the same privilege level.
"AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."
The register has the tweet with actual code for spectre, and more details from the manufacturers and potential fixes. Seriosuly? They're both worth a read.
So, is AMD effected or not? This seems fairly important. The Google blog post sort of goes against itself in this regard. AMD itself has said:
"The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time."
So either AMD is lying or Google's blog post is wrong. Granted AMD's statement is a bit muddled, not sure if they mean they aren't susceptible to all THREE variants (as in only 1/3) or they aren't susceptible to ALL three variants (as in none of them.)
That's what I'm thinking, effected by Spectre, but not by Meltdown. But more clarity would be appreciated on Google and AMD's front. I mean from a pure PR angle, AMD has a lot to gain if they can clear the air more.
We have empirically verified the vulnerability of several Intel processors to Spectre attacks, including Ivy Bridge, aswell and Skylake based processors. We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones.
So in other word, the researcher haven't tried it on AMD processors, but they think the attack would work. AMD, on the other hand, is saying the attack won't work.
Frankly, I believe in PoC||GTFO, so AMD is safe in my book for now.
Spectre and Meltdown are two different exploits. In this case, the paper is talking about Spectre and they did have a POC that worked on all three major processor families (except for deterministic execution engines in microcontrollers and low end CPUs from ARM as well as a few early Atoms from Intel). AMD is saying that Meltdown, which at first glance seems like the most serious one, doesn't effect their processors.
That seems like a rather fragile interpretation of the statement. I had interpreted it to mean they tried the attack on Ryzen and it worked. Given the general nature of their technique why would it not work on AMD chips?
As almost everyone seems to be getting this wrong: It's "affected", not "effected". "effected" means roughly "caused", while "affected" means roughly "influenced".
So, as I gather, one of the main culprits is that unwinding of speculatively executed commands is done incompletely. That is something that the people doing the unwinding must have noticed and known. Somewhere the decision must have been made to unwind incompletely for some reasons (performance/power/cost/time).
As for the difference between AMD and intel. (From other posts here, not this one.) The speculative execution can access arbitrary memory locations on intel processors while this is not possible on AMD. This means that on intel processors you can probe any memory location with only limited privileges.
As for the affected AMD and ARM processors I'm none the wiser. How are they affected? Which models are affected? Does it allow some kind of privilege escalation? The next days will surely stay interesting.
You can't unwind completely. Once the cache is full, to load something on the cache, it has to evict something else. You might be able to evict what you just loaded, but you can't undo the earlier eviction.
Only if your speculative reads do cause irreversible side-effects on those caches. You could implement them in a way that doesn't modify the caches... but that would be complicated and probably use more power and have lower performance.
One of the main reasons for speculative execution is to fetch data into the caches ahead of them being needed. If you don't modify the cache, then you throw that away.
May be one way would be to use a smaller, separate cache for speculative execution and then copy that value to the regular cache once speculation is confirmed? This would add a one cycle latency for cache-to-cache transfer but there might be better ways.
This might actually improve performance because it would prevent actually-hot data being evicted from the cache in favour of cold data that was loaded in a not-taken speculated branch.
It is not enough. The cache line still need be evicted (or at least marked as no longer exclusive) from other cpus, so the side effect is still visible.
There does not need to be a performance hit, but cache complexity must rise: speculative execution must use a separate cache for any data that was fetched speculatively. Only when that branch is truly accepted must that data enter the "real" cache. As long as speculative execution does not go on for too long, these secondary caches can stay really tiny (a handful of cache lines maybe).
The "speculation time" can be hundreds of cycles if you have a branch or memory read that takes a long time to resolve.
This problem is already solved with speculative writes to main memory - a speculative store buffer keeps a sequence of memory operations which need to be done when the operation retires. These buffers are very power hungry, because every future speculative read must check every entry in the speculative store buffer to see if it is re-reading a previously written address. That many to many mapping leads to an exponential amount of checking logic.
The same could be done for cache reads/writes, but I have a feeling it would quickly get very complex, large, and power hungry.
Those hundreds of cycles of speculative execution can't include more than a handful of cache modifications though, because a change to the caching state implies a miss in the speculated execution itself. So you can't have more than a small number of those before the original stall is over and the misprediction resolved.
What you are describing is sinply plain associative memory. If I remember correctly, this is complex in its imolementation, but does not grow exponentially. Plesse correct me if I am wrong.
fully associative memory is generally very power hungry.
Thats why in CPU's caches are usually "2 way associative" or "4 way associative".
That means the data you're looking for might be in one of 2 (or 4) places. Fully associative means the data you're looking for might be in any memory slot, and you're gonna have to check them all. Checking them all in parallel is possible, so it isn't a speed issue, but it is a massive power issue. Average power use is the main limiting factor in CPU's today.
In general in a CPU, transistors which stay in the same state don't use much power. Transistors changing state use power. In a fully associative memory, the transistors doing the comparing change state with every comparison. Whereas with a regular memory only the transistors for the individual bit of the memory being read or written change state and use power.
(the above is a simplification, but contains the key elements).
Associative memory is a huge matrix of and gates in the comparator. But we are talking about buffering results of speculated reads after a predicted branch.
The density if load instructions in code is not particularly high on average. Also, all loads are subject to the same latencies, so that the chance that a speculative read completes before the blocking one is also low (must be cached in a higher level cache, I think).
Taken together, I would be surprised if more than about 10 speculative reads can successfully complete at all in that time frame, even though it is hundreds of cycles. So that would be around 1000 and gates and 1000 memory cells. Doesn't sound too big to me.
More broadly, potential counter-
measures limited to the memory cache are likely to be
insufficient, since there are other ways that speculative
execution can leak information. For example, timing ef-
fects from memory bus contention, DRAM row address
selection status, availability of virtual registers, ALU ac-
tivity, and the state of the branch predictor itself need to be considered.
... also ...
Of course, speculative execution will also affect conventional side channels, such as power and EM
Historically I think it's been assumed that you can't extract much useful information from a modern speculating CPU via EM radiation, but these attacks constantly seem to be surprising people. Re-programming a wifi chip to monitor interference generated by the CPU to spy on speculation? It would have sounded like a pie in the sky fantasy ... yesterday.
I will be highly impressed if anyone managed to pull of a reliable and generic side channel attack based on the hardware you listed. Most of what you describe is squarely in the realm of tinfoil hattery.
DRAM and the memory bus is also affected by DMA operations running independently of the CPU.
Power consumption? There is no hardware available to measure that, let alone at the time resolution required. If you have to first attach a GHz bandwidth oscilloscope to the computer you might as well just reboot it or dump its RAM contents or whatever.
Forget about reprogramming a Wi-Fi chip. They operate on narrow channels in the 2.4GHz range and have fixed hardware for modulation. You would at least have to force the CPU to switch to the right frequency and then be lucky enough that it radiates a signal that demodulated to something sensible within the Wi-Fi hardware. This is physically impossible on current hardware.
Also, on a different note, we cannot sacrifice performance willy-nilly for the sake of a bit of potential security gains. A 30% performance loss on servers means that the counter move is to consume 30% more power to maintain current levels of operation in a data center. This energy needs to be generated, which means that someone is burning oil or gas for it with all the consequences. In essence, the current patches will result in an extra thousands or millions of tons of CO2 in the atmosphere. More efficient replacement hardware will eventually produced with extra environmental impact. We need to find ways to avoid that. Soon.
"Testing also showed that an attack running on one virtual machine was able to access the physical memory of the host machine, and through that, gain read-access to the memory of a different virtual machine on the same host."
This basically kills cloud computing for anything sensitive using shared hardware. In the short term this will actually be good for cloud providers because the demand for dedicated instances will shoot up as there is no short-term alternative.
Which could mean huge sales for Intel, or even AMD, if Amazon, DigitalOcean, Linode and others want to rush to get that lost performance back.
Going to AMD would be incredibly expensive as you'd be replacing nearly everything, but if Intel gets new chips out in a reasonable amount of time, they might actually make a killing on this.
> The infrastructure that runs Compute Engine and isolates customer workloads from each other is protected against known attacks. This also means that customer VMs are protected against known, infrastructure-based attacks from other malicious VMs.
"Compute Engine customers must update their virtual machine operating systems and applications so that their virtual machines are protected from intra-guest attacks and inter-guest attacks that exploit application-level vulnerabilities."
"Compute Engine customers should work with their operating system provider(s) to download and install the necessary patches."
Chrome is listed as impacted due to javascript being able to read memory from outside the browser sandbox.
"In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it." - from the spectre paper
> In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it.
(granted I think site isolation, if enabled, mitigates crossing domain boundaries)
It goes on to show a sample JS impl that JITs into the expected insns using V8.
the big if is whether javascript code that can exploit this can be written. (edit: that's a yes, from the pdf itself...) if yes, nobody's safe, as any webpage (any webpage, even that ad in an iframe) could in theory read your password if it's anywhere in RAM.
Firefox and Chrome have both started posting mitigation strategies. They're mentioned in other comments, some depending on making time functions less accurate since this is a timing attack.
> The infrastructure that runs Compute Engine and isolates customer workloads from each other is protected against known attacks. This also means that customer VMs are protected against known, infrastructure-based attacks from other malicious VMs.
This means that Customer A's VM cannot attack Customer B's VM.
However, if the OS inside the VM is unpatched, then code inside the VM can attack other code inside the VM. If for example you install some malware on your VM, it could use this attack.
(I am not a security expert, this is just my understanding and not a official Google statement)
Spectre is a much more serious bug I feel, but it requires the VM to run the malicious code snippet inside itself and with the right context, not from other guest VM, that is how I understand this. The kinda bug that would totally destroy cloud as a business is the one that other guest VM can read your memory...which doesn't seem like to be the case, for now...
We should quote OpenBSD's Theo de Raadt here, all the way back from 2007:
"x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit."
Speculative execution seems like something that would be very intuitively insecure even to a layperson(relative to the field of course).
I'm wondering, was this vulnerability theorized first and later found out to be an actual vulnerability? Or was this something that nobody had any clue about?
I'm only saying this, because from a security perspective, I imagine somewhere at some point very early on someone had to have pointed out the potential for something like speculative execution to eventually cause security problems.
I just don't understand how chip designers assumed speculative execution wouldn't eventually cause security problems. Is it because chip designers were prioritizing performance above security?
Speculative execution isn't supposed to leak information; if the speculative instructions aren't supposed to execute, all traces of them should be rolled back. I'd be curious to see what the details of this bug really are. I'm not sure how much will be disclosed in the interests of keeping exploits from popping up.
Long time ago, in a far away office park there was an intense discussion over so called "flag early" and "flag after" designs.
Flag early camp argument was - protected pages should not be allowed to be fetched to begin with by any insecure execution flow, and we need to pagefault before speculative execution
The "flag after" camp was all for post-factum pagefaulting when the branch has finished execution, so you do not need to pagefault for every branch, and only do it for the branch that has "won"
Chip design magazines from nineties has all that well covered.
...and for those of us who leave JS off by default except for a few very trusted sites, the bar for turning on JS on a site that asks to just went up a lot higher.
> We are posting before an originally coordinated disclosure date of January 9, 2018 because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation.
That's funny, but also makes me wonder how you get contracted to do logos for things like this. Based strictly on her LinkedIn, she doesn't work for Google. Maybe a friend of someone? Kind of a cool gig though.
> Want to know what's really going on with the Intel security flaw everyone is talking about? Checkout https://meltdownattack.com to get all the details. This is my boyfriend's and his research team's latest work. An huge security breach which affects nearly all your computers! Stealing all your secrets never was that easy!
Both domains were registered on 2017-12-22. Given the planned disclosure on 9th January that Google mentions and MS and others coding patches silently [1], do the early reports [2] of kernel patches, does this mean that due to coding in the open the whole disclosure procedure has been vastly accelerated?
I wonder how the timing relates to New Year and many companies having holidays in CW1.
Accelerated, but not vastly. Google's post says "We reported this issue to Intel, AMD and ARM on 2017-06-01", so the embargo still ended up holding for 7 months, even with it ending a week early. The domain registration dates of 2017-12-22 seem to be just when Google started to prepare for releasing the publicity materials, not when the vulnerability was discovered.
The Google Security Blog post actually says that the open development did not cause the early breakdown of the embargo in the last 1-2 hours, but
> We are posting before an originally coordinated disclosure date of January 9, 2018 because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation. The full Project Zero report is forthcoming.
The problem isn't "it's not bought forward by that much relatively" in as much as you have an agreed timeline to have coordinated patches (e.g so one org doesn't push a fix before other orgs have). So if you have a bunch of orgs set up to do a release on day X, and then publish on X-[whatever] then you are effectively zero-daying.
Is it super important in this case? shrug.
But imagine for the sake of argument there was some undocumented cpu behaviour "if instruction x,y,z are executed in that order with these constants then catch fire", then having anyone pre-empt the agreed update time could be bad.
Some researchers had independently create and demonstrated working PoC based on the linux patches they saw which read kernel memory from user space. At that point it was already public.
After that its all about PR and getting people prepared for the magnitude and impact early.
Also to let people know that patches that were already available can be used (restarting GCP/AWS instances, SPI on chrome).
>running on the host, can read host kernel memory at a rate of around 1500 bytes/second,
I kinda get how it works now. They force a speculative execution to do something with a protected memory address, and then measure the latency to guess the content. They did not found a way to continue execution after a page fault as rumors were.
The fact that speculative execution branch can access protected memory, but not to commit its own computation results to memory in ia32 was known since pentium 3 times.
It was dismissed as "theoretical only" vulnurability without possible practical application. Intel kept saying that for 20 years, but here it is, voila.
The ice broke in 2016 when Dmitry Ponomarev wrote about first practical exploit scenario for this well known ia32 branch prediction artifact. Since then, I believe, quite a few people were trying all and every possible instruction combination for use in timing attack until somebody finally got one that works that was shown behind closed doors.
Edit: google finally added reference to Ponomarev's paper. Here is his page with some other research on the topic http://www.cs.binghamton.edu/~dima/
That's unclear, to the point of being factually wrong. Variant 2 and Variant 3 POCs only affect Intel, and those are the ones people are most talking about, and at least to me, the most concerning.
Treating them as a group, ignores the very real differences in effect.
>6.4 Limitations on ARM and AMD
We also tried to reproduce the Meltdown bug on several
ARM and AMD CPUs. However, we did not manage
to successfully leak kernel memory with the attack described
in Section 5, neither on ARM nor on AMD. The
reasons for this can be manifold. First of all, our implementation
might simply be too slow and a more optimized
version might succeed. For instance, a more shallow
out-of-order execution pipeline could tip the race
condition towards against the data leakage. Similarly,
if the processor lacks certain features, e.g., no re-order
buffer, our current implementation might not be able to
leak data. However, for both ARM and AMD, the toy
example as described in Section 3 works reliably, indicating
that out-of-order execution generally occurs and
instructions past illegal memory accesses are also performed.
Seems like the possibility exists that AMD/ARM could be affected, based on the behavior they saw, but they were not able to successfully verify.
That's fair, but the leads on multiple press releases are that this affects all processors equally which feels very disingenuous to me. Intel's latest press release for example.
the intel behaviour is probably the result of an optimization / architectural decision. like when the micro ops fetch a value from memory they are probably fetching the real value then setting a flag that the instruction is invalid. like it might be cheaper to deal with the problem later in the pipeline than earlier.
but it might also be reasonable in a different architecture to fetch 0 straight away to the micro op when the memory access is invalid and set a flag to raise the exception as well. in this situation you don't have the problem because you are just shuffling around invalid data.
Yes, AMD is affected. There are multiple vulnerabilities (Project Zero refers to 3 separate "variants", variant 1 and 2 being called "Spectre" and variant 3 being called "Meltdown"). The most serious variant only affects Intel, but can be patched. The other 2 variants affect AMD, ARM, and Intel, and cannot be patched.
See this excerpt from spectreattack.com:
>Which systems are affected by Meltdown?
>Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.
>Which systems are affected by Spectre?
>Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.
> We have some ideas on possible mitigations and provided some of those ideas to the processor vendors; however, we believe that the processor vendors are in a much better position than we are to design and evaluate mitigations, and we expect them to be the source of authoritative guidance.
Intel: "Recent reports that these exploits are caused by a “bug” or a “flaw” [..] are incorrect."
So much for "authoritative guidance", fuck these guys.
> Arm recognises that the speculation functionality of many modern high-performance processors, despite working as intended, can be used in conjunction with the timing of cache operations to leak some information as described in this blog.
I personally don't agree, but I guess they're trying to avoid needing to issue a recall for over ten years worth of CPUs?
Then surely you must also argue that all data-dependent, side-channel attacks, such as key recovery attacks against some cryptographic algorithm implementations, are the fault of the hardware.
Unlike Intel, ARM and AMD are implicated only where the attacker can inject code or data (specifically data that is manipulated by pre-existing vulnerable code) into the target address space. The particular kernel exploits require injection of a JIT-compiled eBPF program, as they said they were unable to locate any suitable gadgets in existing compiled kernel code. I wouldn't rule out gadgets being found in the future, but much like cryptographic software timing attacks, the proper fix is to refactor sensitive software logic to be data independent. There's no way to implement an out-of-order, superscalar architecture and protect against this stuff simply because of the nature of memory hierarchies. All you can do is 1) ensure that privilege boundaries are obeyed (like AMD and ARM do, but Intel notable doesn't), and 2) provide guaranteed, constant-time instructions that programmers and compilers can reliably and conveniently leverage. Unfortunately, all the hardware vendors have sucked at providing #2 (much timing resilient cryptographic software relies on implicit, historical timing behavior, not architecturally guaranteed behavior), but it nonetheless still requires cooperation by software programers, making it a shared burden.
Also, FWIW, basically everybody outside the Linux echo chamber has known that eBPF JIT and especially unprivileged eBPF JIT was a disaster waiting to happen. This is only the latest exploit it's been at the center of, and the 2nd in as many months. The amount of attention and effort that has gone into securing eBPF is remarkable, but at the end of the day even if you could muster all the best programmers for as much time as you wanted it's still an exceptionally risky endeavor. Everything we know about the evolution of exploits screams that unprivileged eBPF JIT is an unrelenting nightmare. But it's convenient, flexible, and performant, and at the end of the day that's all people really care about, including most Linux kernel engineers. The nature of the Linux ecosystem is that even if Linus vetoed unprivileged eBPF JIT (optional or not), vendors would have likely shipped it anyhow. It's an indictment of the software industry. Blaming hardware vendors (except for the Intel issue) is just an excuse that perpetuates the abysmal state of software security.
>The particular kernel exploits require injection of a JIT-compiled eBPF program, as they said they were unable to locate any suitable gadgets in existing compiled kernel code
Did they say that?
I don't see anything saying they were unable to, just that they didn't bother to because it would take effort.
>But piecing gadgets together and figuring out which ones work in a speculation context seems annoying. So instead, we decided to use the eBPF interpreter, which is built into the host kernel - while there is no legitimate way to invoke it from inside a VM, the presence of the code in the host kernel's text section is sufficient to make it usable for the attack, just like with ordinary ROP gadgets.
The quote you have is for exploiting Variant 2, the post above yours was talking about Variant 1. For Variant 1, the authors say:
To be able to actually use this behavior for an attack, an attacker needs to be able to cause the execution of such a vulnerable code pattern in the targeted context with an out-of-bounds index. For this, the vulnerable code pattern must either be present in existing code, or there must be an interpreter or JIT engine that can be used to generate the vulnerable code pattern. So far, we have not actually identified any existing, exploitable instances of the vulnerable code pattern; the PoC for leaking kernel memory using variant 1 uses the eBPF interpreter or the eBPF JIT engine, which are built into the kernel and accessible to normal users.
For Variant 1, the "vulnerable code pattern" they're looking for has to be of a very specific type, it's not a run-of-the-mill gadget. It has to load from an array with a user-controlled offset, then mask out a small number of bits from the result and use that as an offset to load from another array, where we can then time our accesses to that second array.
However, they also go on to say:
A minor variant of this could be to instead use an out-of-bounds read to a function pointer to gain control of execution in the mis-speculated path. We did not investigate this variant further.
Could somebody please coin a name for this? Wikipedia currently calls it "Intel KPTI flaw", but that is very vague. It's quite difficult to talk about something without a simple easy-to-remember name.
> Meltdown breaks all security assumptions given by address space isolation as well as paravirtualized environments and, thus, every security mechanism building upon this foundation.
> On affected systems, Meltdown enables an adversary to read memory of other processes or virtual machines in the cloud without any permissions or privileges, affecting millions of customers and virtually every user of a personal computer.
Has Google the best security team in the world? It seems like Google security is in a complete different league. I cannot imagine how this impacts companies handling fiat money or cryptocurrencies in the cloud like Coinbase in AWS.
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?
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.
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)
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.
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.
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".
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! :-)
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.
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.
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?
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.
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...
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.
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).
>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...
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.
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.
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”?)
638 comments
[ 4.4 ms ] story [ 312 ms ] threadCurious. All other reports I've read state that AMD CPUs are not vulnerable.
https://news.ycombinator.com/item?id=16064545
From the Spectre note (which does affect AMD):
In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it.
How quickly are we going to see attacks targeting BTC/ETH wallets, apps etc. on clients and cloud hosted exchanges?
I think the key to the statement is in any case that you need to differentiate between what is possible on the processor architecture level when you have full software control, and what is possible on an operating system level, where 3rd party applications are further restricted in various arbitrary ways such as only allowed to use Java, limited access to high resolution timing primitives, etc. that can make practical exploitation impossible, even if the flaw is present.
It's difficult to reason about because it's hard to tell if you can manipulate a JIT runtime into generating the code you need for the exploit to work - and as the JavaScript implementations show, the answer is often "yes".
But the sentence you quote adds AMD back into play. Maybe some of its ARM processors? e.g. AMD Opteron A1100?
Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (called "Intel Haswell Xeon CPU" in the rest of this document)
AMD FX(tm)-8320 Eight-Core Processor (called "AMD FX CPU" in the rest of this document)
AMD PRO A8-9600 R7, 10 COMPUTE CORES 4C+6G (called "AMD PRO CPU" in the rest of this document)
An ARM Cortex A57 core of a Google Nexus 5x phone [6] (called "ARM Cortex A57" in the rest of this document)
https://googleprojectzero.blogspot.com/2018/01/reading-privi...
> We have also verified the attack’s applicability to AMD Ryzen CPUs.
[1] https://meltdownattack.com/meltdown.pdf
[2] https://spectreattack.com/spectre.pdf
[1] https://developer.arm.com/support/security-update
(Edit: there are 9 posts total, go to her user page to see them all)
Seems there are two issues. One, called Meltdown, only effects Intel and is REALLY bad, but the kernel page table changes everyone is making fixes it.
The other, dubbed Spectre, is apparently common to the way all processors handle speculative execution and is unfixable without new hardware.
I’d like to know more about that but I haven’t seen anything yet.
Whoever discovered this stuff on Google’s team deserves some sort of computer security Nobel prize.
You can see all the tweets here (courtesy of @svenluijten): https://twitter.com/i/moments/948681915485351938.
Thanks for the handy link.
> The business/economic implications are not clear, since eventually the only way to eradicate the threat posed by Spectre is to swap out hardware.
Is this fully accurate, there's no software mitigation available now?
From [0], the above may be true:
> There is also work to harden software against future exploitation of Spectre, respectively to patch software after exploitation through Spectre .
There is 'work'? No current patch? So Spectre is unpatched?
This point doesn't seem to be being highlighted but appears particularly important.
[0] https://meltdownattack.com/#faq-fix
On the positive side, the flaw is very difficult to exploit in a practical setting.
Is it?
"As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs"
See: https://blog.mozilla.org/security/2018/01/03/mitigations-lan...
Moreover the option 2) already exists for large customers and security sensitive applications (e.g. CIA dedicated cloud built by Amazon).
The flag has a fixed fee in the thousands of dollars and each instance is 10% more expensive.
Major props to the teams working on this... now time for us all to hold onto our pants as we ask for budget increases that will make shareholders demand blood.
The only sorts of companies where server costs could increase hugely due to a sudden need for hardware isolation are those where they're running tiny or incredibly bursty workloads. Big companies like Netflix that use tons of cores can just binpack their work all together on the same hardware so their jobs only share hardware with other jobs controlled by the same company. Effectively, cloud providers will start offering sub-clouds into which only your own jobs will be scheduled.
This is actually how cloud tech has worked for many years internally. I worked at Google for a long time and their cluster control system (Borg) had a concept called "allocs" which were basically scheduling sub-domains. You could schedule an alloc to reserve some resources, and then schedule jobs into the alloc which would share those resources. Allocs were often used to avoid performance-related interference from shared jobs, e.g. when a batch job kept hogging the CPU caches and slowing down latency sensitive servers. I suppose these days VMs and containers do a similar job, though I think the Borg approach was nicer and more efficient.
I guess this sort of per-firm isolation will become common and most companies costs won't change a huge amount. The people it'll hit will be small mom-and-pop personal servers, but they're unlikely to care about side channel attacks anyway. So I wouldn't sell stock in cloud providers just yet.
While they're not as big of a deal AFAIK, we do have the Pwnie Awards: https://pwnies.com/
Speculative execution is fundamental to getting decent performance out of a CPU. Without it you should probably divide your performance expectations by 5 at least.
Rolling back all state rather than just user visible state in the CPU is neigh on impossible. When you evict something from the cache, you delete it. Undeleting is hard. There are also a lot of other non-user-visible bits of state in a CPU.
I guess part of the question you're raising is: are there so many different caches, translation buffers, etc. in a modern CPU that keeping 'uncommitted buffers' for the state of all of them would be just as complex as throwing a whole other core in there?
The scary thing is that you can't fix this in software.
[1] https://eprint.iacr.org/2016/613.pdf
> Both hardware thread systems (SMT and TMT) expose contention within the execution core. In SMT, the threads effectively compete in real time for access to functional units, the L1 cache, and speculation resources (such as the BTB). This is similar to the real-time sharing that occurs between separate cores, but includes all levels of the architecture. [...] SMT has been exploited in known attacks (Sections 4.2.1 and 4.3.1)
That said, the main new ingredient of Spectre seems to be the idea that userspace can poison the branch target buffer to cause speculative execution of arbitrary code in kernel space. That part of the attack should be fairly easy to mitigate with new hardware, by XORing (or hashing) the index into the BTB with a configurable value that depends on the privilege level. So each process has its own "nonce", and they're all different from the kernel's.
Then BTB poisoning won't work unless the attacker knows its own and the other context's nonce. Even if further attacks are found that leak this nonce, they could be mitigated by changing the nonce at regular intervals.
https://googleprojectzero.blogspot.com/2018/01/reading-privi...
What!
https://www.fool.com/investing/2017/12/19/intels-ceo-just-so...
> Q: Am I affected by the bug?
> A: Most certainly, yes.
Scary.
Though of course a M7 isn't running VMs, and probably isn't running any kind of attacker-controlled code (scripting included - its there, but rare), so many of the vectors aren't present.
[0]: https://xenbits.xen.org/xsa/advisory-254.html
edit: well it didn't take a nation state after all: https://twitter.com/brainsmoke/status/948561799875502080 - given that, you can be sure that everybody who counts is frantically launching these on your clouds gathering whatever they can.
I am by no means a computer security guru - I just did a CPU architecture course at uni and figured I'd cowboy up an implementation. It worked nearly first time, and can read both kernel and userspace pages from userspace by fooling the branch predictor into going down the wrong path, and relying on the permission checks to be slower than the data reads from a virtually addressed cache. It can only access stuff already cached though, so you can't do a full memory dump with it.
I'd be curious how those two statements should be reconciled.
https://googleprojectzero.blogspot.com/2018/01/reading-privi...
> So far, there are three known variants of the issue:
> Variant 1: bounds check bypass (CVE-2017-5753) > Variant 2: branch target injection (CVE-2017-5715) > Variant 3: rogue data cache load (CVE-2017-5754)
> During the course of our research, we developed the following proofs of concept (PoCs):
> A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.
> A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]
> A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.)
> A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache.
If I'm reading this right, then the only POC that works against ARM is the first one, which lets you read data within the same process. Not too impressive. (Yes, I know that I'm reading into this that they tried to run all the POCs against all the processors. But the "Tested Processors" section lower down leads me to believe that they did in fact do so.)
The third and fourth POC seem to be Intel-specific.
So it seems like they tried it on AMD and ARM, but they tried much harder on Intel. That's less reassuring than my initial reading.
- http://www.zdnet.com/article/security-flaws-affect-every-int...
* Edit:
From https://meltdownattack.com/
Which systems are affected by Meltdown?
"Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.
Which systems are affected by Spectre?
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors."
AMD's ASID blocks the issues for VM guests (and root users on VM guests).
For variant 2, Project Zero used the eBPF interpreter as a gadget, a fake branch destination, without having to actually create an eBPF program or use the normal userland-facing eBPF APIs at all. And they only chose it as the least "annoying" option (see quote below).
edit: I'm not sure how ASID support would mitigate either of those variants, though there may be something I'm not thinking of. (It would help with variant 3, but that's the variant AMD wasn't vulnerable to in the first place.)
quote:
> At this point, it would normally be necessary to locate gadgets in the host kernel code that can be used to actually leak data by reading from an attacker-controlled location, shifting and masking the result appropriately and then using the result of that as offset to an attacker-controlled address for a load. But piecing gadgets together and figuring out which ones work in a speculation context seems annoying. So instead, we decided to use the eBPF interpreter, which is built into the host kernel - while there is no legitimate way to invoke it from inside a VM, the presence of the code in the host kernel's text section is sufficient to make it usable for the attack, just like with ordinary ROP gadgets.
I totally understand how the breaking out of the javascript sandbox attack works and the fact that IPT won't help with that. With Linux's clone(), you could clone without CLONE_VM and use CLONE_NEWUSER|SYSVMSEM and then unmap everything except the Javascript interpreter / JIT and leave a shared memory map and communicate only via the shared memory map and SYSV semaphores for synchronisation. Obviously this wouldn't be available on other platforms.
For variant 1, you would need to find some legitimate kernel code, accessible by syscall, that looks at least somewhat similar to the example in the Project Zero blog post:
In practice, you may not be able to find something nice like "((value&1)*0x100)+0x200", but even if it simply used 'value' as an index, you would be able to at least narrow it down to a range. Other code patterns may work too (and potentially be more powerful?), e.g. conditional branches based on 'value'.For variant 2, see caf's answer to you in another thread.
The attack allows to read all the memory. Isn't there a way to scan for passwords or ssh keys and turn that into a privilege escalation?
KASLR is not enabled everywhere, and where it is, there are other attacks to defeat it, which are mentioned in the paper.
See the section "Reading host memory from a KVM guest / Locating the host kernel". It's terribly clever.
What I was wondering was for local OS user mode to local OS root / kernel mode access; i.e. user to kernel privilege escalation.
What would block it is flushing the branch predictor state when switching privilege levels and/or address spaces.
If I'm understanding the post correctly it says that JIT's not required for Intel CPUs, but is required for AMD.
BPF is employed by the `bpf()` syscall for socket packet filtering, as well as by `seccomp` itself for its syscall filtering. Is this threat vector not available to untrusted processes?
https://elixir.free-electrons.com/linux/v4.15-rc6/source/ker...
> AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.
And Axios [2] that Zdnet quotes gave a comment from AMD:
> "To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time. We expect the security research to be published later today and will provide further updates at that time."
And a comment from ARM: > Please note that our Cortex-M processors, which are pervasive in low-power, connected IoT devices, are not impacted.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/...
[2] https://www.axios.com/how-the-giants-of-tech-are-dealing-wit...
1. Have out of order execution
2. Have aggressive speculative memory load / caching behavior
3. Be able to speculatively cache memory not owned by the current process (either kernel or otherwise)
4. Have deterministic ways of triggering a speculative load / read to the same memory location
2 is probably the saving grace in ARM / low power land, given they don't have the power budget to trade speculative loads for performance (in the event they're even out of order in the first place).
Caveat: I'm drinking pretty strong Belgian beer while reading through these papers.
"AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."
The AMD engineer could be right if talking about Ryzen, and/or he isn't mentioning user-user and user-kernel boundaries.
AMD isn't affected in nearly the same way as Intel/ARM are: https://twitter.com/ryanshrout/status/948683677244018689
"The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time."
So either AMD is lying or Google's blog post is wrong. Granted AMD's statement is a bit muddled, not sure if they mean they aren't susceptible to all THREE variants (as in only 1/3) or they aren't susceptible to ALL three variants (as in none of them.)
We have empirically verified the vulnerability of several Intel processors to Spectre attacks, including Ivy Bridge, aswell and Skylake based processors. We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones.
So in other word, the researcher haven't tried it on AMD processors, but they think the attack would work. AMD, on the other hand, is saying the attack won't work.
Frankly, I believe in PoC||GTFO, so AMD is safe in my book for now.
There is a nice table on AMD's website though:
https://www.amd.com/en/corporate/speculative-execution
As for the difference between AMD and intel. (From other posts here, not this one.) The speculative execution can access arbitrary memory locations on intel processors while this is not possible on AMD. This means that on intel processors you can probe any memory location with only limited privileges.
As for the affected AMD and ARM processors I'm none the wiser. How are they affected? Which models are affected? Does it allow some kind of privilege escalation? The next days will surely stay interesting.
May be one way would be to use a smaller, separate cache for speculative execution and then copy that value to the regular cache once speculation is confirmed? This would add a one cycle latency for cache-to-cache transfer but there might be better ways.
This problem is already solved with speculative writes to main memory - a speculative store buffer keeps a sequence of memory operations which need to be done when the operation retires. These buffers are very power hungry, because every future speculative read must check every entry in the speculative store buffer to see if it is re-reading a previously written address. That many to many mapping leads to an exponential amount of checking logic.
The same could be done for cache reads/writes, but I have a feeling it would quickly get very complex, large, and power hungry.
Thats why in CPU's caches are usually "2 way associative" or "4 way associative".
That means the data you're looking for might be in one of 2 (or 4) places. Fully associative means the data you're looking for might be in any memory slot, and you're gonna have to check them all. Checking them all in parallel is possible, so it isn't a speed issue, but it is a massive power issue. Average power use is the main limiting factor in CPU's today.
In general in a CPU, transistors which stay in the same state don't use much power. Transistors changing state use power. In a fully associative memory, the transistors doing the comparing change state with every comparison. Whereas with a regular memory only the transistors for the individual bit of the memory being read or written change state and use power.
(the above is a simplification, but contains the key elements).
The density if load instructions in code is not particularly high on average. Also, all loads are subject to the same latencies, so that the chance that a speculative read completes before the blocking one is also low (must be cached in a higher level cache, I think).
Taken together, I would be surprised if more than about 10 speculative reads can successfully complete at all in that time frame, even though it is hundreds of cycles. So that would be around 1000 and gates and 1000 memory cells. Doesn't sound too big to me.
More broadly, potential counter- measures limited to the memory cache are likely to be insufficient, since there are other ways that speculative execution can leak information. For example, timing ef- fects from memory bus contention, DRAM row address selection status, availability of virtual registers, ALU ac- tivity, and the state of the branch predictor itself need to be considered.
... also ...
Of course, speculative execution will also affect conventional side channels, such as power and EM
Historically I think it's been assumed that you can't extract much useful information from a modern speculating CPU via EM radiation, but these attacks constantly seem to be surprising people. Re-programming a wifi chip to monitor interference generated by the CPU to spy on speculation? It would have sounded like a pie in the sky fantasy ... yesterday.
DRAM and the memory bus is also affected by DMA operations running independently of the CPU.
Power consumption? There is no hardware available to measure that, let alone at the time resolution required. If you have to first attach a GHz bandwidth oscilloscope to the computer you might as well just reboot it or dump its RAM contents or whatever.
Forget about reprogramming a Wi-Fi chip. They operate on narrow channels in the 2.4GHz range and have fixed hardware for modulation. You would at least have to force the CPU to switch to the right frequency and then be lucky enough that it radiates a signal that demodulated to something sensible within the Wi-Fi hardware. This is physically impossible on current hardware.
Also, on a different note, we cannot sacrifice performance willy-nilly for the sake of a bit of potential security gains. A 30% performance loss on servers means that the counter move is to consume 30% more power to maintain current levels of operation in a data center. This energy needs to be generated, which means that someone is burning oil or gas for it with all the consequences. In essence, the current patches will result in an extra thousands or millions of tons of CO2 in the atmosphere. More efficient replacement hardware will eventually produced with extra environmental impact. We need to find ways to avoid that. Soon.
Holy shit.
Going to AMD would be incredibly expensive as you'd be replacing nearly everything, but if Intel gets new chips out in a reasonable amount of time, they might actually make a killing on this.
"Compute Engine customers should work with their operating system provider(s) to download and install the necessary patches."
For home computer, standard office use, there is no impact at this point, right?
"In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it." - from the spectre paper
> In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it.
(granted I think site isolation, if enabled, mitigates crossing domain boundaries)
It goes on to show a sample JS impl that JITs into the expected insns using V8.
Edit - mixing it up with this other article (https://security.googleblog.com/2018/01/todays-cpu-vulnerabi...)
Doesn't Google say that they are protected...?
However, if the OS inside the VM is unpatched, then code inside the VM can attack other code inside the VM. If for example you install some malware on your VM, it could use this attack.
(I am not a security expert, this is just my understanding and not a official Google statement)
Meltdown on the other hand can do everything. But only on Intel.
"x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit."
https://marc.info/?l=openbsd-misc&m=119318909016582&w=2
I'm wondering, was this vulnerability theorized first and later found out to be an actual vulnerability? Or was this something that nobody had any clue about?
I'm only saying this, because from a security perspective, I imagine somewhere at some point very early on someone had to have pointed out the potential for something like speculative execution to eventually cause security problems.
I just don't understand how chip designers assumed speculative execution wouldn't eventually cause security problems. Is it because chip designers were prioritizing performance above security?
https://news.ycombinator.com/item?id=16062223
It's a similar situation to other timing attacks, which have been around practically as long as caches.
Flag early camp argument was - protected pages should not be allowed to be fetched to begin with by any insecure execution flow, and we need to pagefault before speculative execution
The "flag after" camp was all for post-factum pagefaulting when the branch has finished execution, so you do not need to pagefault for every branch, and only do it for the branch that has "won"
Chip design magazines from nineties has all that well covered.
https://news.ycombinator.com/item?id=16066165
With this particular computer scientist, who talked about this problem before, referenced in Google's paper:
http://www.cs.binghamton.edu/~dima/
Because this looks real bad:
> Reading host memory from a KVM guest
Yeah, it's pretty bad.
Yes, this explains why it was lifted.
Information site with some more information, and links to papers on the two vulnerabilities, called "Meltdown" and "Spectre" (with logos, of course).
(https://meltdownattack.com/ goes to the same site)
says:
> Want to know what's really going on with the Intel security flaw everyone is talking about? Checkout https://meltdownattack.com to get all the details. This is my boyfriend's and his research team's latest work. An huge security breach which affects nearly all your computers! Stealing all your secrets never was that easy!
> Both the Meltdown and Spectre logo are free to use, rights waived via CC0. Logos are designed by Natascha Eibl.
I wonder how the timing relates to New Year and many companies having holidays in CW1.
[1] https://lists.freebsd.org/pipermail/freebsd-security/2018-Ja...
[2] https://news.ycombinator.com/item?id=16046636
> We are posting before an originally coordinated disclosure date of January 9, 2018 because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation. The full Project Zero report is forthcoming.
Is it super important in this case? shrug.
But imagine for the sake of argument there was some undocumented cpu behaviour "if instruction x,y,z are executed in that order with these constants then catch fire", then having anyone pre-empt the agreed update time could be bad.
After that its all about PR and getting people prepared for the magnitude and impact early.
Also to let people know that patches that were already available can be used (restarting GCP/AWS instances, SPI on chrome).
I kinda get how it works now. They force a speculative execution to do something with a protected memory address, and then measure the latency to guess the content. They did not found a way to continue execution after a page fault as rumors were.
The fact that speculative execution branch can access protected memory, but not to commit its own computation results to memory in ia32 was known since pentium 3 times.
It was dismissed as "theoretical only" vulnurability without possible practical application. Intel kept saying that for 20 years, but here it is, voila.
The ice broke in 2016 when Dmitry Ponomarev wrote about first practical exploit scenario for this well known ia32 branch prediction artifact. Since then, I believe, quite a few people were trying all and every possible instruction combination for use in timing attack until somebody finally got one that works that was shown behind closed doors.
Edit: google finally added reference to Ponomarev's paper. Here is his page with some other research on the topic http://www.cs.binghamton.edu/~dima/
> These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them.
https://security.googleblog.com/2018/01/todays-cpu-vulnerabi...
Treating them as a group, ignores the very real differences in effect.
https://googleprojectzero.blogspot.com/2018/01/reading-privi...
>6.4 Limitations on ARM and AMD We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.
Seems like the possibility exists that AMD/ARM could be affected, based on the behavior they saw, but they were not able to successfully verify.
but it might also be reasonable in a different architecture to fetch 0 straight away to the micro op when the memory access is invalid and set a flag to raise the exception as well. in this situation you don't have the problem because you are just shuffling around invalid data.
See this excerpt from spectreattack.com:
>Which systems are affected by Meltdown?
>Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.
>Which systems are affected by Spectre?
>Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.
Intel: "Recent reports that these exploits are caused by a “bug” or a “flaw” [..] are incorrect."
So much for "authoritative guidance", fuck these guys.
> Arm recognises that the speculation functionality of many modern high-performance processors, despite working as intended, can be used in conjunction with the timing of cache operations to leak some information as described in this blog.
I personally don't agree, but I guess they're trying to avoid needing to issue a recall for over ten years worth of CPUs?
Unlike Intel, ARM and AMD are implicated only where the attacker can inject code or data (specifically data that is manipulated by pre-existing vulnerable code) into the target address space. The particular kernel exploits require injection of a JIT-compiled eBPF program, as they said they were unable to locate any suitable gadgets in existing compiled kernel code. I wouldn't rule out gadgets being found in the future, but much like cryptographic software timing attacks, the proper fix is to refactor sensitive software logic to be data independent. There's no way to implement an out-of-order, superscalar architecture and protect against this stuff simply because of the nature of memory hierarchies. All you can do is 1) ensure that privilege boundaries are obeyed (like AMD and ARM do, but Intel notable doesn't), and 2) provide guaranteed, constant-time instructions that programmers and compilers can reliably and conveniently leverage. Unfortunately, all the hardware vendors have sucked at providing #2 (much timing resilient cryptographic software relies on implicit, historical timing behavior, not architecturally guaranteed behavior), but it nonetheless still requires cooperation by software programers, making it a shared burden.
Also, FWIW, basically everybody outside the Linux echo chamber has known that eBPF JIT and especially unprivileged eBPF JIT was a disaster waiting to happen. This is only the latest exploit it's been at the center of, and the 2nd in as many months. The amount of attention and effort that has gone into securing eBPF is remarkable, but at the end of the day even if you could muster all the best programmers for as much time as you wanted it's still an exceptionally risky endeavor. Everything we know about the evolution of exploits screams that unprivileged eBPF JIT is an unrelenting nightmare. But it's convenient, flexible, and performant, and at the end of the day that's all people really care about, including most Linux kernel engineers. The nature of the Linux ecosystem is that even if Linus vetoed unprivileged eBPF JIT (optional or not), vendors would have likely shipped it anyhow. It's an indictment of the software industry. Blaming hardware vendors (except for the Intel issue) is just an excuse that perpetuates the abysmal state of software security.
Did they say that?
I don't see anything saying they were unable to, just that they didn't bother to because it would take effort.
>But piecing gadgets together and figuring out which ones work in a speculation context seems annoying. So instead, we decided to use the eBPF interpreter, which is built into the host kernel - while there is no legitimate way to invoke it from inside a VM, the presence of the code in the host kernel's text section is sufficient to make it usable for the attack, just like with ordinary ROP gadgets.
To be able to actually use this behavior for an attack, an attacker needs to be able to cause the execution of such a vulnerable code pattern in the targeted context with an out-of-bounds index. For this, the vulnerable code pattern must either be present in existing code, or there must be an interpreter or JIT engine that can be used to generate the vulnerable code pattern. So far, we have not actually identified any existing, exploitable instances of the vulnerable code pattern; the PoC for leaking kernel memory using variant 1 uses the eBPF interpreter or the eBPF JIT engine, which are built into the kernel and accessible to normal users.
For Variant 1, the "vulnerable code pattern" they're looking for has to be of a very specific type, it's not a run-of-the-mill gadget. It has to load from an array with a user-controlled offset, then mask out a small number of bits from the result and use that as an offset to load from another array, where we can then time our accesses to that second array.
However, they also go on to say:
A minor variant of this could be to instead use an out-of-bounds read to a function pointer to gain control of execution in the mis-speculated path. We did not investigate this variant further.
Which seems much less reassuring.
They are adding a new instruction to control speculation...
Edit: has been settled, it's https://en.wikipedia.org/wiki/Meltdown_(security_bug) .
> On affected systems, Meltdown enables an adversary to read memory of other processes or virtual machines in the cloud without any permissions or privileges, affecting millions of customers and virtually every user of a personal computer.
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)
[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.
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.
> We would like to thank Intel for their professional handling of this issue through communicating a clear timeline and connecting all involved researchers.
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".
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
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.
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?
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 doesn't really care if it is cloud or bare metal. They are equally vulnerable unless disconnected from internet.
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...
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
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.
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).
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"
https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9...
Its a technique, not a flaw in js, from my understanding
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.
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.
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.
Spectre occurs no matter you are in cloud or not, while cloud companies can advertise themselves to help customers proactively to mitigate such risks.
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”?)