Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security The Internet

New NetSpectre Attack Can Steal CPU Secrets via Network Connections (bleepingcomputer.com) 63

Posted by msmash from the furthering-their-reach dept.
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 discussion has been archived. No new comments can be posted.

New NetSpectre Attack Can Steal CPU Secrets via Network Connections More

New NetSpectre Attack Can Steal CPU Secrets via Network Connections

Comments Filter:

  • Easily blocked with correct network config (Score:1)

    by Anonymous Coward
    This is not news... just set up your network correctly and you're golden.
  • 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.

    • Re: (Score:1)

      by aliquis ( 678370 )

      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)

      by Misagon ( 1135 )

      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

  • 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)

    by LittlePud ( 1356157 ) on Friday July 27, 2018 @05:38PM (#57021418)

    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.

  • Total horseshit (Score:3, Insightful)

    by GerryGilmore ( 663905 ) on Friday July 27, 2018 @06:08PM (#57021550)
    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!

    • Does not know the domain (Score:5, Informative)

      by mangastudent ( 718064 ) on Friday July 27, 2018 @06:33PM (#57021660)

      This latest "Net/S/M" calls them "gadgets", but they are fucking malware!

      "Gadget" is a term of art from return-oriented programming [wikipedia.org]; as the good Wiki introduces this:

      [...] a computer security exploit technique that allows an attacker to execute code in the presence of security defenses such as executable space protection and code signing.

      In this technique, an attacker gains control of the call stack to hijack program control flow and then executes carefully chosen machine instruction sequences that are already present in the machine's memory, called "gadgets"....

      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.

      • But still, must not the attacker need to gain access - by actually running on the target machine - to gain control of the call stack?
        • Read the Wikipedia article further, the start of a ROP attack required exploiting a bug in the code of the target machine like a stack buffer overrun. Which is woefully easy, especially on Windows, which is also a primary target due to its ubiquity. The gadgets are required because execution on the stack is now generally disallowed.
          • OK, I get that, but if I know of a stack buffer overrun on a particular Windows machine, don't I still have to execute *some* code to gather anything? Also, again, how exactly does one gather anything useful from what is essentially a small slice of unknown cache data?

            • 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)

                by Anonymous Coward

                So basically once you've got arbitrary code execution on the remote machine, you can do what ever you want?

                No shit.

                • So basically once you've got arbitrary code execution on the remote machine, you can do what ever you want?

                  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

                  • OK, now you're falling into the paranoia level - from ANY kind of realistic standpoint!
                    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?!?

                    • 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

        • 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

      • like in commonly used DLLs or shared libraries

        Loaded in random memory locations in all modern OSes.

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

          Loaded in random memory locations in all modern OSes.

          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.

          • 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)

      by Anonymous Coward

      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

  • The 15 bit/hour limit makes me skeptical. What relevant information can you hope to stand in the cache for hours?
    • None. It's a proof of concept. However, (as the article mentions) just as the Rowhammer attack on RAM seemed too slow to worry about when first found, the shear number of machines affected means security researchers are going to keep picking at this, and thus it seems inevitable that netSpectre will be a huge problem in the not too distant future.

    • Re: (Score:1)

      by Anonymous Coward

      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

      • 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"

  • 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)

      by ChoGGi ( 522069 )

      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.

Slashdot Top Deals

You do not have mail.

Close