Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Google Android Security

Google Says Almost All CPUs Since 1995 Vulnerable To 'Meltdown' And 'Spectre' Flaws (bleepingcomputer.com) 269

Catalin Cimpanu, reporting for BleepingComputer: Google has just published details on two vulnerabilities named Meltdown and Spectre that in the company's assessment affect "every processor [released] since 1995." Google says the two bugs can be exploited to "to steal data which is currently processed on the computer," which includes "your passwords stored in a password manager or browser, your personal photos, emails, instant messages and even business-critical documents." Furthermore, Google says that tests on virtual machines used in cloud computing environments extracted data from other customers using the same server. The bugs were discovered by Jann Horn, a security researcher with Google Project Zero, Google's elite security team. These are the same bugs that have been reported earlier this week as affecting Intel CPUs. Google was planning to release details about Meltdown and Spectre next week but decided to publish the reports today "because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation."
This discussion has been archived. No new comments can be posted.

Google Says Almost All CPUs Since 1995 Vulnerable To 'Meltdown' And 'Spectre' Flaws

Comments Filter:
  • This isn't even surprising that the problem exists in almost every CPU since a long time considering that most CPUs share the same type of logic in order to achieve the best performance. But performance and security often comes into conflict.

    • by hey! ( 33014 )

      Actually in this case I think "strategy" rather than "logic" is probably a better way of putting it. Everyone uses speculative evaluation to speed things up, Intel just does it slightly more aggressively than other chipmakers and so presents a slightly larger attack surface.

  • by dehachel12 ( 4766411 ) on Thursday January 04, 2018 @09:06AM (#55861845)
    Shouldn't that be : Almost All Intel processors?
    • by Lothsahn ( 221388 ) <Lothsahn@@@SPAM_ ... u_bastardsyahocm> on Thursday January 04, 2018 @09:08AM (#55861859)
      No. Spectre affects AMD and ARM as well (and likely other architectures too).

      Best I can tell, the only CPUs guaranteed not affected by both are in-order architectures, which many older ARM (and extremely old x86) chips are.

      These attacks are a sort of new category of security analysis--realizing that out of order execution can have side effects, and that programs can check for those side effects to leak program state and system memory.
      • by zifn4b ( 1040588 )

        These attacks are a sort of new category of security analysis--realizing that out of order execution can have side effects, and that programs can check for those side effects to leak program state and system memory.

        Not really. Sophisticated security attacks written in ASM have been around for decades. I have a friend who has worked for a decade as a security contractor for federal agencies and they are well aware of this sort of thing. I think what's happened is the knowledge to be able to architect these types of exploits is known to a relatively small group of people that have highly specialized knowledge. Most of the exploits we see these days are effectively script kiddies but in some cases very effect. Back

        • It was a well known technique used for amusement in USA. Till someone in Karachi, Pakistan decided it would be nice to be a little malicious about it. That is how the C-Brain virus was born, back in 1984-85 time frame.
      • by Z00L00K ( 682162 )

        But older architectures has other kinds of security gaps instead. So going back isn't going to help either.

        And today we essentially only have ARM and x86 architectures to care about. Sparc is a fringe architecture, so is PowerPC and MIPS, which means that it really doesn't matter if these architectures are impacted or not.

        • by Misagon ( 1135 )

          SPARC, MIPS and PowerPC may be fringe but they are still out there in the fringe for servers and/or supercomputers.
          Several CPUs of each architecture were released in 2017.

          IBM's POWER chips have supported the full PowerPC ISA for a decade and its performance is very competitive to Intel XEON, if not surpassing.

          Oracle (which had bought Sun) closed their SPARC processor group last year though. Fujitsu may still be active.

          Chinese Loongson makes MIPS processors at 1.5GHz, but they would need to step it up to com

      • by ilguido ( 1704434 ) on Thursday January 04, 2018 @09:50AM (#55862129)
        Meltdown is the real problem here and that affects only all Intel CPUs since 1995 (except for Itanium and pre-2013 Atom) and one [sic!] ARM chip (I think Cortex-A75).

        Spectre is linked to two vulnerabilities: the first one is difficult to exploit and solvable via software, the second one is very difficult to exploit. Spectre allows to read memory from the same process, so it is an issue only for JIT and VM code. Meltdown allows to read memory everywhere.
        • Spectre allows to read memory from the same process, so it is an issue only for JIT and VM code. Meltdown allows to read memory everywhere.

          The paper appears to claim that Spectre can read memory from a different process, provided it can get that process to do things by giving input to it.

      • by blind biker ( 1066130 ) on Thursday January 04, 2018 @10:10AM (#55862227) Journal

        No. Spectre affects AMD and ARM as well (and likely other architectures too).

        Best I can tell, the only CPUs guaranteed not affected by both are in-order architectures, which many older ARM (and extremely old x86) chips are.

        These attacks are a sort of new category of security analysis--realizing that out of order execution can have side effects, and that programs can check for those side effects to leak program state and system memory.

        Spectre is a red herring - there is no known way it can be exploited. Meltdown is far more dangerous and it can be exploited RIGHT NOW with a simple Javascript executed in a browser. Researchers demonstrated a Javascript exploit that uses Meltdown - and there is no telling who has already been compromised. But one thing is sure: non-Intel users have not been compromised.

        Frankly, this whole hoopla about Spectre seems like a well orchestrated deflection stunt by Intel PR operations. And your posts smells a bit of sockpuppetry.

        • by sl3xd ( 111641 ) on Thursday January 04, 2018 @11:45AM (#55862877) Journal

          Frankly, this whole hoopla about Spectre seems like a well orchestrated deflection stunt by Intel PR operations.

          I'd caution against a false sense of security, based on one's choice of processor for your personal desktop.

          There's no disagreement that "Meltdown" is the greater problem, and affects pretty much any Intel chip still functioning. It's important to remember that it's virtually guaranteed that connect to many servers that uses an affected processor every day. Those of us who maintain cloud infrastructures are particularly unhappy with the situation.

          The fact that Meltdown is worse shouldn't distract from the fact that Spectre is bad.

          The paper on Spectre [spectreattack.com] is written by a number of people working for a number of organizations, but Intel isn't one of them. It has the following statement:

          We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones

          They go on to state they've verified the weakness on x86 using C and JavaScript (+ Google V8 JIT) bytecode.

          Much like JavaScript cryptocurrency mining , the fact that something is hard doesn't mean it's not worth doing to those interested, and having browser-based JavaScript exposing data isn't a good thing.

          Meltdown can be fixed fairly easily (AMD certainly shows it's possible to avoid the problem). Spectre, however, will be with us for a long time.

          • by Anonymous Coward

            I once had a job with a company contracted to install server farms for the DOD and some other agencies. I had a fairly low level clearance and was hired right away. I was promoted when they found out I had a Solaris cert, becasue most of the server farms were running Sun blade servers with Sparc processors even though intel blades which were faster and cheaper were available.

            One day, at lunch, I asked about this, and his comment stuck with me. he basically told me that most of the DOD and other intelligence

        • Spectre is a red herring - there is no known way it can be exploited.

          Yet.

          non-Intel users have not been compromised

          So far.

          Frankly, this whole hoopla about Spectre seems like a well orchestrated deflection stunt by Intel PR operations. And your posts smells a bit of sockpuppetry.

          Intel had nothing to do with it; all three issues were found by Google Project Zero (who didn't name them; GPZ doesn't do silly vulnerability marketing games), and then independently by other researchers.

          Note that I'm not trying to defend Intel. I'm an AMD fanboy from way back, and I'd love to see this give AMD a major boost in sales for a few years. But let's not get overconfident. This is a brand new class of attack and few security researchers have focused on it yet. There will be more attac

        • by martyros ( 588782 ) on Thursday January 04, 2018 @12:35PM (#55863261)

          Spectre is a red herring - there is no known way it can be exploited.

          Google has exploited it. Look at Google Project Zero's write-up [blogspot.co.uk] of these bugs. Spectre corresponds to "Variant 1 and Variant 2" in that blog post. You'll see that they successfuly exploit both, the second from a KVM guest.

          It is true that Google cheat a little here, by using Linux's eBPF JIT engine (which, I hear, is normally disabled by default). From the blog post:

          To be able to actually use this behavior for an attack, an attacker needs to be able to cause the execution of such a vulnerable code pattern in the targeted context with an out-of-bounds index. For this, the vulnerable code pattern must either be present in existing code, or there must be an interpreter or JIT engine that can be used to generate the vulnerable code pattern. So far, we have not actually identified any existing, exploitable instances of the vulnerable code pattern; the PoC for leaking kernel memory using variant 1 uses the eBPF interpreter or the eBPF JIT engine, which are built into the kernel and accessible to normal users.

      • by MSG ( 12810 )

        No. Spectre affects AMD and ARM as well (and likely other architectures too).

        AMD CPUs were demonstrated to be vulnerable to Spectre under Linux only in a non-standard kernel configuration. In the standard configuration, they demonstrated "the ability to read data within the same process, without crossing privilege boundaries."

        It's possible that future research will reveal vulnerabilities on AMD CPUs, but as of now, I don't see that one has been verified under the standard kernel configuration. (So don't enable eBPF JIT)

        • Technically, Spectre only reveals data to which the process had already access to begin with.

          In the Google demo, it works because all in-kernel code (here: JIT-ed bytecode) has access to in-kernel data.
          There's a reason why the option is non-standard.

          In the few affected browser, it works because said browsers were stupid enough to keep sensitive data (passwords ?) in the same process as where remotely provided Javascript code is JITed and executed.
          (I.e.: stupid design that should be fixed anyway. If not Spec

      • Does anyone know if this will affect PowerPC, SPARC, Alpha, and MIPS as well?

        • by emil ( 695 )

          This seems to focus on branch prediction and the impact of backing the pipeline contents. The error seems to center on taking a branch into privileged memory that is initiated by unprivileged code. Therefore, any CPU with branch prediction is likely suspect.

      • arm32 versus AArch64 (Score:4, Informative)

        by emil ( 695 ) on Thursday January 04, 2018 @11:12AM (#55862669)

        32-bit ARM may be safer, because speculative execution is much, much more difficult there.

        The program counter is a visible register that can be manipulated by any opcode - an explicit JUMP or BRANCH is not necessary. This makes branch prediction mostly impossible.

        Most opcodes are conditional. This dependency between adjacent instructions is also a huge obstacle for speculative execution.

        32-bit ARM is mostly in-order for these reasons.

        https://www.jwhitham.org/2016/02/risc-instruction-sets-i-have-known-and.html [jwhitham.org]

        Design errors, like having r15 as the program counter or making every instruction conditional, are problems for CPU architects rather than programmers, and it's no surprise that they disappeared in the 64-bit version of the ARM architecture. They must have made it awfully hard to implement superscalar, out-of-order execution.

        • by tlhIngan ( 30335 ) <slashdot.worf@net> on Thursday January 04, 2018 @01:33PM (#55863729)

          32-bit ARM may be safer, because speculative execution is much, much more difficult there.

          The program counter is a visible register that can be manipulated by any opcode - an explicit JUMP or BRANCH is not necessary. This makes branch prediction mostly impossible.

          Most opcodes are conditional. This dependency between adjacent instructions is also a huge obstacle for speculative execution.

          32-bit ARM is mostly in-order for these reasons.

          :

          This attack is a side effect of out-of-order execution. This did not happen to ARM until the Cortex A8 line of processors (Cortex A7 was still in-order). Not to be confused with ARMv7/ARMv8, since Cortex A7 and A8 implement ARMv7.

          And yes, even in 64-bit ARM PC is a user-visible register - AArch32 and AArch64 are very similar to each other down to instruction coding, too. The only big thing AArch64 eliminates is conditional execution which ARM found with the Cortex A8 to interfere with superscalar execution. But just because it's harder to speculatively execute doesn't mean it's impossible. It just means you execute the instruction and then evaluate the condition later - if the condition turns out to be false, you retire the instruction without posting the effects to the architectural registers. If the instruction is true, you retire it normally. Either way, you consume the same time (an instruction not executed conditionally on ARM is considered a NOP and only wastes processor time. This fact alone makes it worthwhile to execute all conditional instructions and retire them when the end result of the condition is known - you're using up time anyhow).

          Also, I'm sure the Cortex A8 notes which instructions potentially could adjust the PC (the register field of every instruction is well defined, so it's trivial to examine it and determine if it's the PC. In fact, a JMP is syntactic sugar for a MOV, as is RET. They are internally MOV instructions (you'll note that every function ends with "mov pc,lr", which moves the link register (old PC before call) to the PC, thus returning.

          Modern thumb interworking though uses "blx" which is branch-to-link-and-exchange because you need to load both the LR and the old CPSR register (which controls the THUMB state), so you return back to the right mode and is the only way if you're mixing ARM and THUMB instructions together (aka interworking).

      • These attacks are a sort of new category of security analysis--realizing that out of order execution can have side effects, and that programs can check for those side effects to leak program state and system memory.

        They are not new in any shape or form.

        https://eprint.iacr.org/2006/2... [iacr.org]

    • by AHuxley ( 892839 )
      "“Meltdown” and “Spectre”: Every modern processor has unfixable security flaws"
      https://arstechnica.com/gadget... [arstechnica.com]
      • Every modern processor has unfixable security flaws

        Heh. That phrasing is debatable. Release a better processor and the "unfixable" security flaws will have been fixed. ;)

      • "“Meltdown” and “Spectre”: Every modern processor has unfixable security flaws" https://arstechnica.com/gadget... [arstechnica.com]

        Which makes you wonder if this is actually a flaw. A flaw is where something does not work the way it was designed to work. The fact that every modern processor has the same vulnerability suggests that perhaps this was designed into them at some point. I have no evidence that this was designed in, but one should at least entertain the possibility that it was.

        • by Lunix Nutcase ( 1092239 ) on Thursday January 04, 2018 @09:33AM (#55862011)

          Of course it’s a flaw. It’s an unintended side-effect of speculative execution.

          • Are you sure it is unintended?
            • Yes, it really boosts your sales, especially internationally, when the press tells everyone your CPUs are insecure crap. That's why the Intel boss sold his shares in time because he knew that it's going to be a big boon for his company when everyone learns about the problem.

              People, I love a good conspiracy theory like the next guy, but try to create some that are at least plausible.

              • Yes, it really boosts your sales, especially internationally, when the press tells everyone your CPUs are insecure crap

                Well, a lot of people have to buy new CPUs now...

                • Really? Which one? The one from your competitor that allegedly does not have that bug?

                  • Really? Which one? The one from your competitor that allegedly does not have that bug?

                    Possibly, yes. Another possibility is to replace it with a new intel CPU where the bug is fixed, or at least a model where a software fix can be implemented with minimum performance degradation.

              • And exactly what processors are they going to buy instead? According to several sources, EVERY modern processor has this "flaw".
              • by sl3xd ( 111641 )

                Yes, it really boosts your sales, especially internationally, when the press tells everyone your CPUs are insecure crap

                It actually might: many makers (<cough>Apple</cough>) only buy Intel chips, and I wouldn't be surprised if a lot of folks buy a new computer in the (mistaken) belief that will have an updated CPU that fixes the bug.

                Few consumers understand the lead time for hardware to go from an engineer's workstation to fabricated hardware. I wouldn't expect an Intel chip that won't "Meltdown" until 2019 at the earliest.

                That's why the Intel boss sold his shares in time

                The problem (for the prosecutor) is proving to the Jury that it was insider trading. (And t

            • by sl3xd ( 111641 )

              Hanlon's rasor [wikipedia.org] applies pretty well here.

              We can't even design a car with a few thousand parts that doesn't have unintended side effects.

              The idea a machine with billions of transistors won't have unintended side effects is comical at best.

              Processor eratta are maintained by every chip maker -- from the lowliest 4-bit microcontroller all the way up to beasts like Ryzen. This particular problem just happens to be unusually bad, and in a place that can't be fixed with microcode.

        • by AHuxley ( 892839 ) on Thursday January 04, 2018 @09:47AM (#55862109) Journal
          Re but one should at least entertain the possibility that it was.
          A hardware version of PRISM? https://en.wikipedia.org/wiki/... [wikipedia.org]
          Room 641A Inside https://en.wikipedia.org/wiki/... [wikipedia.org] most computers?
          It was interesting how much of the NSA ANT catalog https://en.wikipedia.org/wiki/... [wikipedia.org] connected to a computer rather than was able to work internally on a CPU as shipped?
          Is the world missing the other part of the CPU catalog thats still doing collect it all missions?
        • Re: (Score:2, Interesting)

          by Anonymous Coward

          ...The fact that every modern processor has the same vulnerability suggests that perhaps this was designed into them at some point. I have no evidence that this was designed in, but one should at least entertain the possibility that it was.

          Perhaps we should entertain the possibility that the revelations of Edward Snowden scratch the fucking surface as to the deceptive power and control that the US government holds over US corporations.

          I'd say there's more than enough evidence to suggest this is no fucking "flaw". In fact, the timing of it all tends to suggest the Clipper chip program didn't just go away in the late 90s; it was superseded.

    • Given the sales figures, they're not exactly wrong.
  • by Zorpheus ( 857617 ) on Thursday January 04, 2018 @09:06AM (#55861847)
    You can find this information at the end of the article:

    At the time of writing, Google believes that "every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013)" is affected by Meltdown. Google says it verified Meltdown only against Intel CPUs, but not ARM and AMD. Nonetheless, Intel has a market share of than 80% on desktops and more than 90% on the laptop and server markets, meaning that a large number of desktops, laptops, and servers are affected.

    • AMD seem to think they're not affected by Meltdown: [lkml.org]

      AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

      BTB it is almost certainly this email, sent on 26 December, which led to the Meltdown vulnerability being made public [twitter.com], causin

    • by Misagon ( 1135 ) on Thursday January 04, 2018 @09:55AM (#55862151)

      No, they did test their Meltdown code on AMD and ARM but were not able to reproduce it on the chips they tested on.
      That does not prove that a Meltdown-like attack on AMD or ARM is impossible, either on a different chip they did not test on or with a tweaked version of Meltdown.

      From the actual article ("meltdown.pdf"):

      We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.

      • Yes. What we read in this article is: Google believes that AMD is vulnerable, but they could not prove it. What we don't read here is: AMD says they are not vulnerable.
    • by neo00 ( 1667377 )
      Meltdown only impacts Intel processors. Meltdown can be thought to be a special case of Spectre that exploits an Intel-specific flaw that makes it simpler to execute the exploit.

      Spectre, which is more of a generalized class of attacks, but more difficult to implement, impacts Intel, AMD, and ARM as per the original spectre paper. https://spectreattack.com/spec... [spectreattack.com], from which I quote:

      Hardware. We have empirically verified the vulnerability of several Intel processors to Spectre attacks, including Ivy Bridge, Haswell and Skylake based processors. We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones.

      and

      Unlike Meltdown, the Spectre attack works on non-Intel processors, including AMD and ARM processors. Furthermore, the KAISER patch [19], which has been widely applied as a mitigation to the Meltdown attack, does not protect against Spectre.

      References:
      Spectre https://spectreattack.com/spec... [spectreattack.com]
      Meltdown https://meltdownattack.com/mel... [meltdownattack.com]

      • by sl3xd ( 111641 )

        The paper also appears to insinuate that RISC-V and MIPS might be vulnerable as well.

        RISC-V is so new it's not widely deployed, but MIPS... well, that's in most routers.

  • by xxxJonBoyxxx ( 565205 ) on Thursday January 04, 2018 @09:09AM (#55861869)
    https://meltdownattack.com/

    Meltdown breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system.If your computer has a vulnerable processor and runs an unpatched operating system, it is not safe to work with sensitive information without the chance of leaking the information. This applies both to personal computers as well as cloud infrastructure. Luckily, there are software patches against Meltdown.

    Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre. Spectre is harder to exploit than Meltdown, but it is also harder to mitigate. However, it is possible to prevent specific known exploits based on Spectre through software patches.
    • There's a pretty good summary in the XenProject Security Advisory [xen.org]:

      Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has

    • Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre. Spectre is harder to exploit than Meltdown, but it is also harder to mitigate. However, it is possible to prevent specific known exploits based on Spectre through software patches.

      This paragraph, which you copy-pasted from meltdownattack.com, is not explaining much. I would go as far as to say that it's jackshit. Just read the linked research paper.

      • >> Just read the linked research paper.

        Which is why I provided that URL. None of the clickbait articles had links to the research paperS (plural, MF'er).

        So...you're welcome newbie. Now GTFO my lawn.
        • >> Just read the linked research paper.

          Which is why I provided that URL. None of the clickbait articles had links to the research paperS (plural, MF'er).

          So...you're welcome newbie. Now GTFO my lawn.

          I used singular, because the topic was Spectre, so I only referenced the Spectre paper [spectreattack.com].

          And "newbie"? Who uses that, anymore? I remember it being quite the term, circa 1998.

  • Easy Fix (Score:2, Funny)

    by Anonymous Coward

    Just patch all the CPUs so they process things introspectively, with a glass of wine and some light jazz.

  • What are we supposed to do? Have you seen the price of Amiga and Atari ST computers on eBay? Not to mention that there's nowhere near enough to supply the whole planet!

    Has anyone started working on an OS/9 port of Firefox for the Color Computer 3 yet?

    • You could wrap all your computers in tinfoil. If it works for mind control rays on your head it might for this.

    • What are we supposed to do? Have you seen the price of Amiga and Atari ST computers on eBay? Not to mention that there's nowhere near enough to supply the whole planet!

      My Amiga doesn't have a MMU, you insensitive clod! Luckily I have AMD processors, on which you can mitigate these attacks. Now if I could just figure out how to disable their equivalent of the management engine

    • Looks like I'm going to have to drag my Quadra 700 out of mothballs. Anybody know what the latest version of System 7 is? Just hope my 320MB external hard drive isn't full....

      Hey, anybody got a 56K modem I could borrow?

  • It will be interesting to see how quickly corporations react to this. It could get expensive.
    • by wbr1 ( 2538558 )
      The main expense may come from having to purchase hardware to accommodate for the performance loss inherent in the patch. If you are running a VM farm of some sort, and have provisioned for a certain amount of load or cycle availability for the VMs, a drop in performance could mean not meeting SLA for those VMS and a need for additional hardware to cover the load. This would be a budgetary burden to many.
  • 486 (Score:4, Funny)

    by thegreatbob ( 693104 ) on Thursday January 04, 2018 @09:47AM (#55862107) Journal
    Time to bust out my 486!
    • by erice ( 13380 )

      Time to bust out my 486!

      Don't have to go back that far. Bonnelle and Saltflat (first and second generation) Atoms are strictly in-order. No speculative execution. Just move your server loads to clusters of 2nd generation eeepc's!

  • by JoeyRox ( 2711699 ) on Thursday January 04, 2018 @09:54AM (#55862145)
    I read through Google's Meltdown paper (https://meltdownattack.com/meltdown.pdf [meltdownattack.com]). While there are several cumulative vulnerabilities that make this exploit possible, the most important of which is kernel address-space discovery via speculative data accesses which leave DCACHE lines in their wake, the root vulnerability of actually being able to read the contents of data comes down to an exception race condition. From the document:

    1 ; rcx = kernel address
    2 ; rbx = probe array
    3 retry:
    4 mov al, byte [rcx]
    5 shl rax, 0xc
    6 jz retry
    7 mov rbx, qword [rbx + rax]

    Listing 2: The core instruction sequence of Meltdown. An inaccessible kernel address is moved to a register, raising an exception. The subsequent instructions are already executed out of order before the exception is raised, leaking the content of the kernel address through the indirect memory access.
    ...
    When the uOPs finish their execution, they retire inorder, and, thus, their results are committed to the architectural state. During the retirement, any interrupts and exception that occurred during the execution of the instruction are handled. Thus, if the MOV instruction that loads the kernel address is retired, the exception is registered
    and the pipeline is flushed to eliminate all results of subsequent instructions which were executed out of order. However, there is a race condition between raising this exception and our attack step 2 which we describe below.

    And why AMD and ARM may not be vulnerable to Meltdown:

    6.4 Limitations on ARM and AMD
    We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able tol leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.

  • by nagora ( 177841 ) on Thursday January 04, 2018 @10:01AM (#55862179)
    Someone at Intel has spun BeepingComputer - Google said that nearly all CPUs MADE BY INTEL since 1995 are likely to be vulnerable. Way to rescue your stock price, man. Good work from msmash and /. for repeating the lie too.
  • Reading through a variety of descriptions I understand the attack for Meltdown, but I'm seeing less of a discussion around how patches may work - in particular I read if your model of Intel processor supports PCID (Process-Context Identifiers) a fix may not impact performance as much, but I've not seen any description of why and would be interested to know how that helps.

  • One of the things I've seen flying around, is some people are saying this can be exploited in a web browser, thanks to Javascript JIT-compiling to machine code.

    I am pretty damn out of date on Javascript compilers, so I was hoping someone could explain how this is possible. Javascript doesn't have pointers. I'd think that if a Javascript programmer is capable of writing Javascript code that compiles in such a way that the programmer can create a pointer of their own making (perhaps pointing to kernel memory) and can cause code to dereference that pointer, we would all call that a severe and inexcusible compiler bug.

    I mean, even if there were no processor flaw at all, but the Javascript-compiled-to-x86 code could read arbitrary memory in its own browser process, that alone would be a severe web-user-killing nightmare. How is that not a compiler bug?

    Am I mistaken that a Javascript exploit is possible?

    • Am I mistaken that a Javascript exploit is possible?

      The fact that a given programming language gives you more or less freedom regarding how to deal with the memory management aspects doesn't change the fact that the generated applications rely on memory. In any case all these bugs seem fairly theoretically and very difficult to be actually exploited. It seems more a matter of making sure that computers are 100% safe at their most basic level than actually avoiding imminent threats.

  • Amazon cloud services, Google, Azure are players in the cloud where multiple users share the same unknown processor. Would they be affected? Would they have to stop provisioning virtual machines for different users on the same physical sever? Would it increase their costs and reduce profit margin? Or would it reduce their attractiveness and people would use less cloud services?
  • There seems to be a concerted PR effort to shine spotlight on everything rather than just Intel where it belongs.

    Meltdown is basically heartbleed. This is NOT a side-channel attack. It allows an attacker to trick the processor to flat out be handed the value of memory address the attacker should never be able to access. The only linkage between it and spectre is incidental exploitation of speculative execution.

    Spectre is exclusively a "side-channel" attack. To continue TLS analogy it's like using an AE

If bankers can count, how come they have eight windows and only four tellers?

Working...