Slashdot Mirror
New NetSpectre Attack Can Steal CPU Secrets via Network Connections (bleepingcomputer.com)
Scientists published a paper Friday detailing a new Spectre-class CPU attack that can be carried out via network connections and does not require the attacker to host code on a targeted machine. From a report: This new attack --codenamed NetSpectre -- is a major evolution for Spectre attacks, which until now have required the attacker to trick a victim into downloading and running malicious code on his machine, or at least accessing a website that runs malicious JavaScript in the user's browser. But with NetSpectre, an attacker can simply bombard a computer's network ports and achieve the same results. Although the attack is innovative, NetSpectre also has its downsides (or positive side, depending on what part of the academics/users barricade you are). The biggest is the attack's woefully slow exfiltration speed, which is 15 bits/hour for attacks carried out via a network connection and targeting data stored in the CPU's cache.
It looks like a useless exploit for any practical purpose. I highly doubt the contents of a CPU cache would remain static for long enough to extract any information of value.
Once you read the pdf describing this, anyone who knows anything can come to the same conclusion. Let's look at the facts:
1) In order for this or any of the other Spectre/Meltdown "vulnerabilities" (and I use that term loosely, it's really more of a theoretical/lab setup) require you to be running malware on your system. This latest "Net/S/M" calls them "gadgets", but they are fucking malware!
2) Referencing the basic principles of S/M, basically malware runs a specific set of instructions in a specific sequence to - essentially - tickle the cache by that set/series of instructions to leak some cache data that can then be read by said malware. OK, groovy enough, but how in da hell can you A) know that the cache data you read has not then subsequently over-written by a cache flush on that cache line? and then B) make any reasonable sense out of said data captured? Depending on the size of data gathered, and from what I've read it's pretty tiny, trying to steal "crypto keys" (the big bugbear over at Ars) in this way has to be the most idiotic ever!
Bottom line: use basic security to keep malware off your system and what does leak through will be much more efficient than S/M, so - worry about the REAL shit, please!
It would be a REALLY crappy backdoor. In this case, you're leaving looking at 15 bits per hour of random data, which will most likely be one pixel of a YouTube video or something equally interesting. Completely useless in most cases. Theoretically the bits you get might be a key, but they might also be anything else that the computer handled, and most of what computers handle isn't security keys.
Any time you have cache, things in the cache will be faster to access than things not in the cache. That's kinda the whole point of having a cache, to speed up access to data that is used many times in a row. Caches of various are extremely important to computing, too - the can often make operations an order of magnitude faster. So nothing either sinister or stupid there - it's a simple and cheap method to make the computer run much faster.
These general types of mechanisms will continue to exist, too. The only way you get rid of them, or many of them, is to run a completely separate, very simple (and slow) computer inside your desktop which is only used for security-sensitive operations AND have all applications use it, every time. A separate computer inside your computer, that gets ALL of your security keys? The more paranoid amongst us would have a field day with that.
"Gadget" is a term of art from return-oriented programming; as the good Wiki introduces this:
The "gadgets" are just convenient snippets of code that the attacker knows is already running in the target machine, like in commonly used DLLs or shared libraries.
> even if only random data now. someone will figure out how to get specific data.
They will and they did, it seems. I just read more about it.
The basic attack would be ~random data, but people have combined it with other very clever ideas to be able to target certain memory locations.
In those cases in which they can access memory through the kernel, such as the networking portion of the kernel, address randomization is bypassed.
Just howdafuck is 15 bits per hour of cache data from a heavily used server going to give ANY valid data?!? I am STILL waiting for ANY reasonable explanation and - so far - have heard nothing but a bunch of paranoid "could" shit. SHOW ME!!
How do you know which 2048 bits of memory contains the key? Take a server with 64GiB of RAM, that key takes up 0.000000373% of the memory.
Lets assume you knew which 8MiB block the key was held in, that's still 478 years at 16 bits/hour. Lets assume they can speed it up by a factor 1,000, that's 174 days. If somebody told me their safe was guaranteed to be cracked, but only if somebody worked on it 24 hours a day for 174 days I'd think "that's one fucking secure safe"