New NetSpectre Attack Can Steal CPU Secrets via Network Connections (bleepingcomputer.com) 63
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.
Re: (Score:2)
Neither. Basic cache operation. Until separate sec (Score:3)
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
Re: (Score:2)
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.
Correcting myself - not random data (Score:4, Interesting)
> 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.
Re: (Score:2)
If on a modern system they know which memory address to target they likely already own you box.
Easily blocked with correct network config (Score:1)
Only not-vulnerable computers connect to Internet? (Score:2)
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.
Re: (Score:1)
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.
Re: (Score:2)
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 [arm.com] 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 fo
15 bits/hour for attacks (Score:2)
Sounds slow and boring. I will definitely wait to see this 007 / James Bond sequel NetSpectre on cable...
15 bits per hour (Score:5, Insightful)
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.
Re: (Score:2)
I thought that too while I read it at first, but that isn't true. The likelihood is this would be used to obtain private keys.
A key (even a short symmetric one) is 128 bits, if not 256 (ex: AES). Public/private keys are even longer at 2048 bits.
Even at 60 bits/hour, that’s 2 hours minimum to extract a key. Will the cach contents remain unchanged for that long?
Re: (Score:2)
how long is the data being accessed for, and how often?
Re: 15 bits per hour (Score:2)
What about a VPN router? Eventually, you'd get the full key, just not sure you would know the bit order?
Total horseshit (Score:3, Insightful)
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!
Does not know the domain (Score:5, Informative)
"Gadget" is a term of art from return-oriented programming [wikipedia.org]; 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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You use the smashed stack to execute the gadgets, their being picked as such because they're executable bits of code that can be strung together with the smashed stack into what you want. And since you can execute Turing complete programs using ROP, you can probably arrange for something interesting to be unveiled in cache timing attacks, side channels created by speculative execution that out of order CPUs use to run fast.
You use your ROP code to arrange stuff to be in the cache, or not, and then read tha
Re: (Score:1)
So basically once you've got arbitrary code execution on the remote machine, you can do what ever you want?
No shit.
Re: (Score:2)
On we have to assume all of the fastest CPUs, that do out of order processing including speculative execution. The speculative execution allows setting up side channel attacks like cache timing, and this can, depending of the details, allow you to cross many protection boundaries, between user processes, user to kernel (and not just Meltdown), different threads that were in theory sandboxed (why Chrom
Re: (Score:3)
Please explain - without ignoring my earlier request, i.e. just howdafuck do you either know and/or be able to manipulate any cache-level data gleaned by the most inefficient process known to mankind - you can do ANYTHING by arbitrarily sniffing what is most likely stale and/or recently replaced cache memory?!?
Re: (Score:2)
It's not paranoia, it's been demonstrated on real systems in real time, there was even a good GUI example. These attacks extract useful data at very high rates as these things go, although this initial proof of concept network example is an exception for its slow rate of extraction ... but lots of these proofs of concepts have been sped up as they get explored. That it can be done at all is a big wakeup call.
If you read and understand the previously mentioned original Google Project Zero paper [blogspot.com], "Variant 1
JavaScript on a site, or even just connect tcp (Score:2, Informative)
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 tryi
Re: (Score:3)
Re: (Score:2)
I have shown you, in the Google Project Zero paper. Did you read and understand the section of it I directed you to?
TFS links to the white paper, doesn't it? (Score:2)
If you really want the details, they are in the paper.
https://misc0110.net/web/files... [misc0110.net]
Re: (Score:2)
like in commonly used DLLs or shared libraries
Loaded in random memory locations in all modern OSes.
Re: (Score:2)
By definition, DLLs and shared libraries must provide a way to call the code that's inside them, no matter where in memory they are located. Randomized memory layouts only increase the difficultly of some sorts of attacks, they are not a panacea.
Re: (Score:2)
By definition, DLLs and shared libraries must provide a way to call the code that's inside them, no matter where in memory they are located.
All of which doesn't help at all if your side channel attack specifically is designed to leak out memory contents rather than actually sit there making system calls.
BZZZT (Score:1)
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
15 bit/hour (Score:2)
Re: (Score:2)
Re: (Score:1)
It doesn't have to stay in the cache, it just has to stay in memory. A server with lot's of memory likely keeps a large chunk of the file system in memory for long periods. At 16 bits/hour it would take 128 hours or about 5.3 days to get a 2048 bit key. If the key is accessed all the time, or the system is quiet, or just has a ton of memory, that's not impossible.
In fact, it's quite likely if you have a process that connects to a system to run a command every few minutes. Perhaps some sort of monitoring
Re: (Score:3)
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"
ah, in-depth research sure went into this article (Score:2)
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?
Re: (Score:2)
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.