Are there any nails left? This is most serious of them all. No local code execution needed at all. While 60 bits/hour is small number, it does not mean that there is no vastly improved version of this behind corner.

Graz...

"If the system is fully patched against Spectre, including the new gadget variants we show in the paper, the attack should be prevented. However, we are still at the beginning of understanding how Spectre gadgets can look like, so this is not a problem that is trivial to solve."

Well, so far so good?

fantaskarsef:

Graz... Well, so far so good?

I think that quote you used says that mitigation for netspectre is not included in Spectre patches. Which seems to be consistent with intel's statement:

NetSpectre is an application of Bounds Check Bypass (CVE-2017-5753), and is mitigated in the same manner - through code inspection and modification of software to ensure a speculation stopping barrier is in place where appropriate. We provide guidance for developers in our whitepaper, Analyzing Potential Bounds Check Bypass Vulnerabilities, which has been updated to incorporate this method. We are thankful to Michael Schwarz, Daniel Gruss, Martin Schwarzl, Moritz Lipp, & Stefan Mangard of Graz University of Technology for reporting their research.

"If the system is fully patched against Spectre, including the new gadget variants..." vs "If the system is fully patched against Spectre which includes the new gadget variants..."

Ah, I thought the quote says, that if you apply all the patches that are around so far, it should theoretically work, just that they have not yet toyed with every way to get into a system via a Spectre attack / gadget / kit that they haven't seen / tried yet.

And yet another way of loosing your data. Is there any "overview" of some kind to see what's currently happening in IT sec? Like some "comparision chart" with Intel and AMD and what security flaw affects which systems and when they get / got fixed? Would be nice to see. But to break this info a bit down: Almost every sensitive information you have, passwords, tokens, logins, certificates, etc. wander through your RAM one time or another. At some point everything you do gets shoveled through the RAM. This attack here is a method to get this RAM's content (which itself is a dumb storage of 0's and 1's, the operating system puts those to use and / or protects sensitive parts by not allowing any access or specific access) to be read by some attacker over your network, if possible (means: if your router allows this) even through the internet. To ease any upcoming panic: If I read this correct, the attack was demonstrated through LAN (fastest kind of network possible to get to data, so "best case") and the rate of the data recovered is very low: 15 to 60 bits per hour. That means if you own certificates to secure connections / servers and stuff (those typically are set to some 2048bit or greater key length) this takes:

ideal best case:
2048 : 60 = 34,13 (hours to get the key)

ideal worst case:
4096 : 15 = 237,067 (hours to get the key)

But that was the IDEAL best case, because as they said they couldn't "pinpoint the extraction". RAM gets shifted sometimes (moved to another location), flushed or filled with other stuff. Therefore it can happen you read a part of memory, then read it again after some time and it contains very different values. You are not this lucky to start extraction from the first bit on at the right part. And because an attacker is typically set OUTSIDE of your house, over "internet" this attack is even more unreliable because of the "noise" on the line (other data sent through this line at the time you are listening for the "hacked packets"). And when you do not know where the key you want to extract is stored, good luck finding the right 2048+ bit on a system with 8GB RAM or more. 8GB = 68.719.476.736 bit ... at 15 to 60 bits per hour .... means ~1.145.324.612 hours to process the 8GB RAM, that's ~130.745 YEARS !!!!! (calculated at attacker's "BEST" case with 60bits per hour to put "fear" in your hearts!) So from my perspective: a) This is another security issue which should be taken care of, because CPUs and GPUs get better and better over time (more processing power) so the attack may be more profitable in a few years / decades. b) We don't have to worry about getting hit and successfully "hacked" by this within the next decade (I think).

386SX:

And yet another way of loosing your data. Is there any "overview" of some kind to see what's currently happening in IT sec? Like some "comparision chart" with Intel and AMD and what security flaw affects which systems and when they get / got fixed? Would be nice to see. But to break this info a bit down: Almost every sensitive information you have, passwords, tokens, logins, certificates, etc. wander through your RAM one time or another. At some point everything you do gets shoveled through the RAM. This attack here is a method to get this RAM's content (which itself is a dumb storage of 0's and 1's, the operating system puts those to use and / or protects sensitive parts by not allowing any access or specific access) to be read by some attacker over your network, if possible (means: if your router allows this) even through the internet. To ease any upcoming panic: If I read this correct, the attack was demonstrated through LAN (fastest kind of network possible to get to data, so "best case") and the rate of the data recovered is very low: 15 to 60 bits per hour. That means if you own certificates to secure connections / servers and stuff (those typically are set to some 2048bit or greater key length) this takes:

ideal best case:
2048 : 60 = 34,13 (hours to get the key)

ideal worst case:
4096 : 15 = 237,067 (hours to get the key)

But that was the IDEAL best case, because as they said they couldn't "pinpoint the extraction". RAM gets shifted sometimes (moved to another location), flushed or filled with other stuff. Therefore it can happen you read a part of memory, then read it again after some time and it contains very different values. You are not this lucky to start extraction from the first bit on at the right part. And because an attacker is typically set OUTSIDE of your house, over "internet" this attack is even more unreliable because of the "noise" on the line (other data sent through this line at the time you are listening for the "hacked packets"). And when you do not know where the key you want to extract is stored, good luck finding the right 2048+ bit on a system with 8GB RAM or more. 8GB = 68.719.476.736 bit ... at 15 to 60 bits per hour .... means ~1.145.324.612 hours to process the 8GB RAM, that's ~130.745 YEARS !!!!! (calculated at attacker's "BEST" case with 60bits per hour to put "fear" in your hearts!) So from my perspective: a) This is another security issue which should be taken care of, because CPUs and GPUs get better and better over time (more processing power) so the attack may be more profitable in a few years / decades. b) We don't have to worry about getting hit and successfully "hacked" by this within the next decade (I think).

Who's to say that their LAN attack access is faster than many high value target network access? And who's to say that they came with most efficient vector of attack? On 1st look it looks like they need to push gigabytes of data into victim computer to extract few bytes. But that does not sound right. How many datagrams/bytes has to come via network to forge request for particular access to protected memory? I think they forged method, but far from efficient one.

Fox2232:

Who's to say that their LAN attack access is faster than many high value target network access? And who's to say that they came with most efficient vector of attack? On 1st look it looks like they need to push gigabytes of data into victim computer to extract few bytes. But that does not sound right. How many datagrams/bytes has to come via network to forge request for particular access to protected memory? I think they forged method, but far from efficient one.

LAN is a definition. And I compared LAN to WAN/GAN/whatever, LAN therefore always has the least latency. If they tested on 10mbit LAN or 10gbit LAN, dunno. I only said LAN makes the attack easier (less noise and more control of the noise produced, which is hindering the attack as they wrote) INSTEAD of attacking through the internet / from the outside. And from what I read when I read through my text again, I didn't state this would be the most efficient approach to that. But given the issue is new, this is the most efficient way SO FAR. I only took this exact case, this exact issue into the equation. And if what they did was the current "way to do it", then this is nothing to be scared of. That was all I meant. 😉 And yes, I agree with you, this sounds like they found something, but probably not followed "the best way" to take use of it. Time will tell. Cheers.

386SX:

LAN is a definition. And I compared LAN to WAN/GAN/whatever, LAN therefore always has the least latency. If they tested on 10mbit LAN or 10gbit LAN, dunno. I only said LAN makes the attack easier (less noise and more control of the noise produced, which is hindering the attack as they wrote) INSTEAD of attacking through the internet / from the outside. And from what I read when I read through my text again, I didn't state this would be the most efficient approach to that. But given the issue is new, this is the most efficient way SO FAR. I only took this exact case, this exact issue into the equation. And if what they did was the current "way to do it", then this is nothing to be scared of. That was all I meant. 😉 And yes, I agree with you, this sounds like they found something, but probably not followed "the best way" to take use of it. Time will tell. Cheers.

Just to clarify bit. I used your post as jumping platform. Questions there were meant for everyone to think about. I think that even if this is pretty hard to pull (much harder than other spectre attacks), it is one which is most dangerous, because it does not need any kind of authentication or user mistake. When spectre misuses unprotected browser, it is because user was on site which hosted spectre code. But here it 'only' takes network interface willing to receive and reply. I did not see full details to find out if you just need something like icmp reply, or one needs any opened socket like for RPC (even if it is to throw auth errors, because it is still receiving and sending packets).

I found a solution guys 100% works, cut your Ethernet cable a no boogieman can hurt you. Only downside is no internet 🙁 But seriously this is getting ridiculous now, what on our pc isn't vulnerable at this stage?

Ricepudding:

[...] what on our pc isn't vulnerable at this stage?

BIOS is writable after admin privs are gained. Intel ME is writable in usermode sometimes and in admin mode almost ever and in pre-manufacturing mode (headers set to FF FF FF) everything is writable without any block at all. AMD's ME counterpart is "hackable" like this socalled security professionals found out (cannot and will not remember the name). Content of RAM is readable without any privs at all. (= This issue here) Content of RAM is changeable (bit-flipping) to desired values. USB may contain a keylogger in its physical model embedded (hardware hack) or put between the connector and the cable (like man in the middle). LAN port can house so many security issues it is hilarious and shocking. Sniffing, phishing, fingering (NO, I do NOT talk about women here!!), exploiting encryption, packets, traffic in general by dozens of different attacks (man in the middle, 0day, buffer overflow, side channel, IP/MAC/identity spoofing, etc.) all give you the stuff you want. The soundcard may be hacked to archive different things: send data (yes, you heard right: SEND DATA!), receive data (= malware), bit flipping, malware housing (firmware), crossflashing (flash a BIOS from your PCI soundcard, activate Windows 7 by PCI card, etc.) SATA/IDE/SAS/FC controllers may be manipulated, by intentionally modding a BIOS you may disable them all (render them unusable). By ordering specific commands you could for example let the SSD do full disk defrag every 2 seconds after its previous run (= kill your SSD). Every device what has got a firmware on it (USB, sound, LAN, chipset, Intel ME & AMD's counterpart, etc.) may be altered so it gets unusable or behaves not the way intended. Options are endless. CPU may be altered, because of different tools you could set your OC to insane values and watch the computer POP like popcorn. ... there are more ... definitely! Rule of thumb: If there is ANY logic or storage in there, it is hackable and therefore may not behave as expected. So to answer your question: Nothing is secure, everything is vulnerable. EDIT:

fantaskarsef:

[...] if you apply all the patches that are around so far [...]

Did that once, didn't protect me from malware, even used the USA ones even though I live in Germany: https://ae01.alicdn.com/kf/HTB1cjSoRVXXXXX5XXXXq6xXFXXXw/M-nner-abzeichen-stickerei-Jeans-d-nne-gerade-zerst-ren-patch-jeans-m-nner-hosen-loch.jpg_640x640.jpg :D

If all you're trying to collect is login credentials, 60 bits per hour is plenty fast enough if your hack can't be detected.

I have a theory that someone somewhere wants to sell you some kind of hardware key and device to 100% secure ones electrical goods. Like chip and pin but for log ins. ^^

schmidtbag:

If all you're trying to collect is login credentials, 60 bits per hour is plenty fast enough if your hack can't be detected.

then can it pinpointed to collect only for login credentials ? i think it only work like key-logger, it log-everything rather than specific things except someone add more code for detection.... at that point i believe most security-companies will actively block/remove the threat

slyphnier:

then can it pinpointed to collect only for login credentials ? i think it only work like key-logger, it log-everything rather than specific things

I'm not sure, but that's a good point.

except someone add more code for detection.... at that point i believe most security-companies will actively block/remove the threat

But, kind of the sole reason why Spectre, Meltdown, and their variants are so scary is because they can't be detected. Maybe netspectre can, I'm not sure, but I have a feeling it can't.

schmidtbag:

But, kind of the sole reason why Spectre, Meltdown, and their variants are so scary is because they can't be detected. Maybe netspectre can, I'm not sure, but I have a feeling it can't.

There are few hints: - intel hands out advices on how to code net applications which can't be misused for this attack => not detectable, therefore has to be prevented on micro level - if detectable => not preventable without impact ... Why? Because if I attack your icmp driver and OS responds in blocking library handling those requests, I just successfully executed DoS attack. - > Imagine connecting to RPC, database, tomcat, ... few hundreds of requests and something in OS detects compromised application => killed => Attack successful But affected application can be quite easily coded to kick/block communication with anything that sends it trash. Except applications which accept anonymous connections like web servers. As there getting valid requests vs infected requests would be likely not detectable.