NetSpectre: Read Arbitrary Memory Over Network [pdf] | Hacker News Reader

NetSpectre: Read Arbitrary Memory Over Network [pdf]

misc0110.net

158 pointsrazer622 comments

The AVX side channel is neat. It relies on power management rather than cache: after 1ms of AVX2 inactivity (no 256 bit operations being performed), it goes into a power-saving mode; the next 256-bit operation pays a ~2x cycle penalty. They get 8B/min at low error rate with AVX2.

In Google Cloud, from unrelated instances, they're getting 1 byte every 8 hours (3 if the target has an AVX2 gadget). Attacks tend to get better over time, but still, that's an AES key in a few days, and it assumes one discrete target; in a real deployment, that secret might be mirrored over hundreds of instances.

It's an AES key if you know where to look. Do these style of attacks let you view the memory map or do you just pick a place? How troublesome is this, really? I'm actually curious. I never saw where you find the point in memory to point your Spectre gun.

I'm a little vague on the details, but I think there are some tricks you use to narrow it down and then go spelunking. Maybe a particular variable needs to be in a page aligned struct so you only need to find a magic value at one of N places, etc.

Like I said, I don't know the specifics, but there are methods of doing better than guessing.

This one is going to be much more difficult to defeat. I suspect we will see more dangerous local exploits based on power side channels.

Mitigating those will be bad for power usage and performance. We can imagine future processors will manage cache state differently, keeping all changes local to the core until the relevant instructions retire. I have no idea how you would mitigate functional unit power up / power down without destroying the usefulness of the feature itself.

Maybe just don't speculate across power domains? I.e. if a speculative execution would require bringing up the AVX2 unit that might be a bad idea anyway because it slows down everything else even if the branch is mispredicted.

Or at least execute it on the slow path if the unit is not up (lower execution width) without triggering the ramp-up as long as it is speculative. Only ramp-up when the instruction is committed.

The paper seems to say that they attacked a victim program that was specifically written to include vulnerable gadgets.

Is code for this victim program available? I don't see it in the paper.

Have such gadgets been found in any real-world programs?

Checking a user provided index is valid before using it is certainly a common idiom. There are many reasons why attacking programs in the wild would be more complicated, but delaying publication until then is probably a poor option. The contribution here is not a single attack against vuln ware release 2.3.12, but a new (or expanded) attack class.

Right but didn't we already know that this hypothetical attack class exists? The possibility of remote spectre exploits like this was discussed in the original spectre paper.

It's certainly interesting to construct an example and show it working, but this isn't surprising, is it?

Just trying to understand if I've missed something here.

(The AVX side channel is certainly new and interesting, though!)

Other than the AVX side channel, the interesting thing is that it demonstrates that the remote aspect definitely works. Before, it was theorized but might have proven to never give sufficient signal. While many were confident, now we know.

Further, it shows how to do it (classifier) and gives a very good model for what bandwidth can be expected in practice. And still further, that bandwidth is entirely sufficient for attacking long lived cryptographic key material. Before, it was easy to theorize that the bandwidth would simply be too low. Now it isn't.

This is also really good because the bandwidth is really low. For data larger than a key (or where you would need to scan a lot to find the data), we can be much more comfortable with infeasibility arguments by basing them on some security margin beyond these experiments. As an example, if it would take 1 <timeunit> to exfiltrate a single credit card number even if the technique got 10 times better, maybe that means it isn't a sufficient risk. Or maybe it is. (All depends on the time unit and the risk.) But now we can make that assessment with a real baseline instead of a guess.

Indeed, that makes sense. Thanks!

> This is also really good because the bandwidth is really low.

Until someone improves on this work.

This can pretty much all be laid at the feet of overly complex CPU designs and instruction sets. Looks like complexity is as evil for security in hardware as it is in software.

On the plus side part of why you see more of these kinds of attacks is that we have actually made progress on software security.

> overly complex

Speculative execution is what makes our sequential code fast by exploiting parallel execution pipelines that would otherwise sit idle.

Avoiding this would increase complexity somewhere else, e.g. compilers would have to become even more clever or programmers would have to work harder to reduce the branches in their code. Sprinkling code with annotations to prevent speculative execution around sensitive data is of course just another way complexity does go up to let us keep the performance gains of speculation.

> Avoiding this would increase complexity somewhere else, e.g. compilers would have to become even more clever

Not really. Compilers are already stupendously complicated since they inherit a ton of techniques used for older processors that required, e.g. instruction scheduling and other tricks. CPUs getting bigger and faster just added additional complexity to extract even more dynamic parallelism and also do the job of simpler compilers.

It's much easier to turn off the complexity in a compiler and reason about the resulting program. The complexity in the CPU cannot be switched off and is closed source.

Gimme simple CPUs again.

Complex compilers seem better than complex chips because the former is software and can be fixed.

I'm wondering these days if Intel was onto something with EPIC/Itanium and just failed in the execution.

They were definitely onto something. They made something competitive performance-wise that wasn't vulnerable to all of these speculative execution vulnerabilities.

Itanium's slowness is generally very exaggerated (at least in part because the first Itanium had a rather slow memory subsystem, and the performance kind of sucked as a result). Circa 2008 or so the fastest database servers available were Itanium. Unfortunately, it emulated x86 extremely slowly and amd64 ran x86 very quickly, so AMD kinda ate Intel's lunch.

If I were at Intel management I might explore with engineering resurrecting the Itanium (rebranded and modernized of course). Today with so much open source there is less instruction set lock in, and with all these vulnerabilities you might be able to market it as a more secure architecture. In that case you might only need to equal x64 performance.

I’d be curious the setup the researchers used. The paper doesn’t release the code or stack. It feels contrived but I’d be interested to be able to replicate. Trying in real, production environments, at least so far, has not been able to replicate any bit transfer rate. Has anyone else been able to reproduce? If so, can you share the specifics of your test?

Cool news!

Does anyone know of a good writeup on the original vulnerability that's a little less technical? Like a lot of people on HN I came into programming via systems administration so I don't have a lot of low level knowledge.

Spectre just became a much bigger problem.

not really... this is only a vulnerability in so much as specific gadgets were intentionally placed in code. it's more of a danger for intentional data exfiltration covertly, not an issue of attacking random servers like ssh or web servers to get keys. show me a vulnerable ssh or web server and i'll be worried, otherwise, this is just hype about a new class of theoretical attack that has no known actual real world targets.

to further elaborate, it would take 85 days of 4gbps network link being 100% saturated to leak a 256 bit key, assuming you know the memory locations, assuming no ASLR, assuming the key doesn't move or change, and assuming a vulnerable spectre gadget running on the system, which means you already have RCE in the first place. this class of attack is easily mitigated, and has no real world implications. if you don't notice a 4gbps link being fully saturated for months at a time, you have bigger problems. otherwise, if you don't reboot a server or restart services within 85 days, and if you don't use ASLR, you have bigger problems. if you let someone run spectre code on your system, you have bigger problems.

this class of attack is theoretical, and all the hype is unsubstantiated. clearly y'all haven't read the paper. people never read past the headlines any more...

you don't even have to take my word for it, READ THE PAPER:

> As NetSpectre is a network-based attack, it cannot only be preventedby mitigating Spectre but also through countermeasures onthe network layer. A trivial NetSpectre attack can easily be detectedby a DDoS protection, as multiple thousand identical packets aresent from the same source. However, an attacker can choose anytrade-off between packets per second and leaked bits per second.Thus, the speed at which bits are leaked can simply be reducedbelow the threshold that the DDoS monitoring can detect. This istrue for any monitoring which tries to detect ongoing attacks, e.g., intrusion detection systems. Although the attack is theoretically not prevented, at some point the attack becomes infeasible, as the time required to leak a bit increases drastically. Another method to mitigate NetSpectre is to add artificial noise to the network latency. As the number of measurements depends on the variance in network latency, additional noise requires an attacker to perform more measurements. Thus, if the variance in network latency is high enough, NetSpectre attacks become infeasible due to the large number of measurements required.

Reply on news.ycombinator.com