Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Saturday May 18 2019, @09:57AM   Printer-friendly
from the Hardware dept.

Security researchers have found a new class of vulnerabilities in Intel chips which, if exploited, can be used to steal sensitive information directly from the processor.,

The bugs are reminiscent of Meltdown and Spectre, which exploited a weakness in speculative execution, an important part of how modern processors work. Speculative execution helps processors predict to a certain degree what an application or operating system might need next and in the near-future, making the app run faster and more efficient. The processor will execute its predictions if they're needed, or discard them if they're not.

Both Meltdown and Spectre leaked sensitive data stored briefly in the processor, including secrets — such as passwords, secret keys and account tokens, and private messages.

Now some of the same researchers are back with an entirely new round of data-leaking bugs.

"ZombieLoad," as it's called, is a side-channel attack targeting Intel chips, allowing hackers to effectively exploit design flaws rather than injecting malicious code. Intel said ZombieLoad is made up of four bugs, which the researchers reported to the chip maker just a month ago.

Almost every computer with an Intel chips dating back to 2011 are affected by the vulnerabilities.

ZombieLoad takes its name from a "zombie load," an amount of data that the processor can't understand or properly process, forcing the processor to ask for help from the processor's microcode to prevent a crash. Apps are usually only able to see their own data, but this bug allows that data to bleed across those boundary walls. ZombieLoad will leak any data currently loaded by the processor's core, the researchers said. Intel said patches to the microcode will help clear the processor's buffers, preventing data from being read.

So far ARM and AMD are not known to be affected.

https://techcrunch.com/2019/05/14/zombieload-flaw-intel-processors/


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Saturday May 18 2019, @10:52AM (2 children)

    by Anonymous Coward on Saturday May 18 2019, @10:52AM (#844981)

    These security issues are the byproduct of the chip's design. There will be (many?) more found in each chip until Intel (and AMD and ARM) re-think how speculative execution can be implemented safely. In the mean time don't expect big performance boosts in newer chips because design rather than clock cycles have been driving the increases in throughput for a while now.

  • (Score: 3, Insightful) by bzipitidoo on Saturday May 18 2019, @03:19PM (1 child)

    by bzipitidoo (4388) on Saturday May 18 2019, @03:19PM (#845023) Journal

    It's one of the powers of C. If you don't do bounds checking, garbage collection, memory management or any other of that overhead stuff, your programs run faster.

    This principle has obviously been applied to processors.

    • (Score: 2) by RS3 on Sunday May 19 2019, @03:17AM

      by RS3 (6367) on Sunday May 19 2019, @03:17AM (#845179)

      Yeah, kind of similar I think. Somewhere I had written about my speculative hunch (but not execution!) about the problem. If you know about x86 protected mode, GDT, LDT, etc., you know a bit about how x86 memory protection works. I can't find detailed info on the Sceptre / Meltdown / Zombieland / [what's next], so I'm speculating that the protection works for RAM addresses. But pre-fetch, speculative execution, pipelining, etc., are able to bypass that- reading ahead in RAM, so now someone's code/data is in internal cache/pipeline, and it's evidently fairly trivial to get that data. IE, the address protection circuits would need to keep track of whose what is in cache, pipeline, stack, etc., or flush all caches, pipelines, etc., on context switch. I know a tiny bit about Linux kernel workarounds and that's a lot of what they're doing, but beyond that, not sure how to fix...