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.
This is not news... just set up your network correctly and you're golden.
Comment removed based on user account deletion
Which ARM processors are NOT vulnerable to Spectre and Meltdown? What is the fastest cheap computer not vulnerable?
Maybe only computers with ARM processors should be allowed to connect to the Internet. All other computers in an organization would exchange data using a proprietary system.
Sounds slow and boring. I will definitely wait to see this 007 / James Bond sequel NetSpectre on cable...
It must have been something you assimilated. . . .
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.
There was ARM cpus vulnerable for Spectre though.
But wasn't FX chips free from it?
Simple (some would had said stupid I guess) enough to not be vulnerable.
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!
The 15 bit/hour limit makes me skeptical. What relevant information can you hope to stand in the cache for hours?
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.
ARM cores with out-of-order execution are vulnerable to (regular) Spectre where as most ARM cores with in-order execution are not.
ARM posted a list of which that are affected. (But they use their own nomenclature...)
ARM Cortex-A53 and Cortex-A55 are the fastest 64-bit ARM cores without speculative execution, and yes, I think you'd want to choose 64-bit ARM (AArch64) for new applications.
Cortex-A53 is a bit old and most easily found in the Raspberry Pi 3 Model B and 3 Model B+ single-board computers, with four cores each. Both SBCs are cheap, widely available and have a lot of support. The Model B+ runs cooler and faster (1.4 GHz) than the Model B but both need heat sinks. If a heat sink is included at all in a kit it is often too small to be able to allow the chip to run at full speed for any length of time.
The Cortex-A55 is touted as being 20% faster than the A53 per clock. Most SoCs with the Cortex-A55 are running in a big.LITTLE configuration together with faster cores that run out-of-order.
I have found only one SoC with only A55: the Spreadtrum SC9863, which has eight cores at up to 1.6 GHz. It was announced in May and it is so early that I can't even find a datasheet for it.
Please do comment if you know of another option.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
"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.
this coupled with address randomization bug would allow for known key locations, i of course did not RTFA, this is slashdot yes? but i do know if this is the first time its been done, even if only random data now. someone will figure out how to get specific data.
Until this attack, the attacker needed to run some code, which could be JavaScript. So infect a site, or lure a victim to your site, trumptweettoomuch.com, and you've got your code execution.
The BASIC idea would be your JavaScript does something with the byte 01010111 10,000 times and measures how long that takes, then compares it to the same operation with byte 01011111. That allows you to know if certain other programs are using either of those bytes in their data. Run through a million iterations of trying combinations and you've retrieved the contents of another processes memory - or the kernel memory. That's the part that let's your code step out of its own process.
Combine the ability to read the memory of other processes with a few other clever hacker techniques and you get the ability to read specific memory contents from specific locations.
What's new in this attack is that the attacker doesn't need to run any code on the victim machine. Instead, they send 20,000 packets, half include the 01010111 byte, half include the 01011111 byte. The timing of the network driver, and therefore the timing of the responses, will vary depending on whether a different piece of system software is using the same byte. Combine that with earlier techniques and you have the ability to read the memory of programs running on the machine, without you running any code on the machine.
These are a BIG deal for the theoretical security of the machine. The practical use is much harder, especially over the network. They achieved 15 bits per hour by saturating a direct gigabit connection. That's not very practical, unless you happen to be attacking a VM, coming from another VM on the same host hardware.
> 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.
If you actually read and understand the article, the implications are tremendous. The gadgets you are so worried about are actually code that already exists in the kernel and all over application space. In fact, any well written code will be full of gadgets. Poorly written code might have fewer gadgets in it, but it will still have some.
It's my guess that kernel's and hyper-visors are inherently full of the necessary gadgets for this attack, and it may be impossible to remove them.
The net impact is that any group with money and good pull at any of the major ISPs will be able to use this attack to extract the private keys from any server they care to. It basically means that within a week or two, the NSA will have the private keys to any web server they wish.
I'm currently thinking the only defense is to have your web server generate a new private key every day. Not fun.
Academics achieved higher exfiltration speeds --of up to 60 bits/hour-- with a variation of NetSpectre that targeted data processed via a CPU's AVX2 module, specific to Intel CPUs.
Unless they mean the attack is specific to Intel CPUs with AVX2, but it sure sounds like AVX2 is only an Intel thing?
and replying to myself...
an attacker can simply bombard a computer's network ports
So, rate-limiting when you detect a bombardment? Then it'll be less than 15 bits an hour.
If you really want the details, they are in the paper.
https://misc0110.net/web/files...