Slashdot Mirror


New Spectre 1.1 and Spectre 1.2 CPU Flaws Disclosed (bleepingcomputer.com)

Two security researchers have revealed details about two new Spectre-class vulnerabilities, which they've named Spectre 1.1 and Spectre 1.2. From a report: Just like all the previous Meltdown and Spectre CPU bugs variations, these two take advantage of the process of speculative execution -- a feature found in all modern CPUs that has the role of improving performance by computing operations in advance and later discarding unneeded data. According to researchers, a Spectre 1.1 attack uses speculative execution to deliver code that overflows CPU store cache buffers in order to write and run malicious code that retrieves data from previously-secured CPU memory sections. Spectre 1.1 is very similar to the Spectre variant 1 and 4, but the two researchers who discovered the bug say that "currently, no effective static analysis or compiler instrumentation is available to generically detect or mitigate Spectre 1.1." As for Spectre 1.2, researchers say this bug can be exploited to write to CPU memory sectors that are normally protected by read-only flags.

4 of 109 comments (clear)

  1. Re:Advanced Micro Devices IMMUNE by Eravnrekaree · · Score: 5, Insightful

    Do you work for Intel? AMD is not vulnerable to the newly announced exploits. Also the ones AMD is vulnerable too are low risk and hard to exploit, far lower risk than Intel only ones, which are trivial to exploit. Bottom line: AMD is VASTLY safer.

  2. Quick - Panic! by GerryGilmore · · Score: 1, Insightful

    Can we be real for one moment, please?
    In the realm of software vulnerabilities, these are:
    1) Ridiculously difficult to implement. At the end of the day, you are fundamentally tickling the cache and timing the resultant reads to try to determine the content of that cache. Is there ANY reasonable way to "read" the contents of said cache and determine what context a blob of data means?!?
    2)Beyond trial code that is ALL based on the original POC distributed by virus vendors, etc. there is NO known implementation in the wild.
    3) This requires the virus to be running ON your fucking computer!! If you are running ANY virus on your computer, you're hosed.
    4) Derived from 3), for the forseeable future ANY virus on your system is about 28Giga-times more likely to be a standard, run-of-the-mill virus. Meantime, everyone is running around wanting to burn their CPUs because they are "vulnerable".
    FFS!! Does NO ONE have ANY perspective left anymore?!? /rant

    1. Re:Quick - Panic! by Anonymous Coward · · Score: 5, Insightful

      1) Ridiculously difficult to implement.

      It only has to be implemented once and copied. Re: Life.

      2)Beyond trial code that is ALL based on the original POC distributed by virus vendors, etc. there is NO known implementation in the wild.

      Until viruses use it. Viruses were original POC.

      3) This requires the virus to be running ON your fucking computer!! If you are running ANY virus on your computer, you're hosed.

      Re: Javascript

      4) Derived from 3), for the forseeable future ANY virus on your system is about 28Giga-times more likely to be a standard, run-of-the-mill virus.

      And one based on Meltdown and/or Spectre could potentially bypass all security without any possible generic fix. So, obviously it'd be nice to know about it.

      Meantime, everyone is running around wanting to burn their CPUs because they are "vulnerable". FFS!! Does NO ONE have ANY perspective left anymore?!? /rant

      Yes, /rant. Who's going around burning their CPUs? The point is to find out as many of the vulnerabilities now to start introducing fixes in hardware. And knowing there are more varied variants means the fix needs to be more generic. It also means that we have to start honestly considering the possibility that javascript can be an attack vector against CPU bugs, so that's something to mitigate against where reasonable.

      But, yea, let's not point out the potential scope of this or light an impetus to change CPUs to mitigate these risk! We should just not really cover it. Then if/when the attacks do come because people find out how to make them more doable, we're then really boned. I mean, it's not like it takes years for CPU designs to be developed and deployed to replace current CPUs.

    2. Re:Quick - Panic! by complete+loony · · Score: 3, Insightful

      If I received a dump of memory from a process there's probably a lot I could work out just from a hexdump as well as running strings or grep. I've personally reverse engineered a few proprietary binary file formats by making small changes in an application, then staring at hex dumps of the saved files.

      It's not a huge leap to do the same with the RAM of a target program. Run it in a debugger, make small changes and watch where those changes are written. Once you work out what to look for, then you automate the search in the virus.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.