
NetSpectre: Read Arbitrary Memory Over Network [pdf] - razer6
https://misc0110.net/web/files/netspectre.pdf
======
tptacek
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.

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

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

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

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

~~~
kentonv
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!)

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

~~~
kentonv
Indeed, that makes sense. Thanks!

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

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

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

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

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

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

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

------
djhaskin987
Spectre just became a much bigger problem.

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

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

