Spectre flaws continue to haunt Intel and AMD as researchers find fresh attack method
(2024/10/18)
- Reference: 1729260075
- News link: https://www.theregister.co.uk/2024/10/18/spectre_problems_continue_amd_intel/
- Source link:
Six years after the Spectre transient execution processor design flaws were disclosed, efforts to patch the problem continue to fall short.
Johannes Wikner and Kaveh Razavi of Swiss university ETH Zurich on Friday [1]published details about a cross-process Spectre attack that derandomizes [2]Address Space Layout Randomization and leaks the hash of the root password from the Set User ID (suid) process on recent Intel processors. The researchers claim they successfully conducted such an attack.
[3]Spectre refers to a set of attacks made possible because of the way processors conduct speculative execution - a performance optimization technique that involves making calculations in advance. The results can be used if needed, or otherwise discarded.
[4]
Branch prediction is a form of speculative execution, and modern processors use it to make guesses about the path a program will take. It's related to branch target prediction, which attempts to predict the target address of the next instruction to be executed in a given branch.
[5]
[6]
Spectre attacks try to make the branch predictor forward an incorrect prediction – such that when the processor executes the associated instructions, it accesses out-of-bounds memory that contains secrets like passwords or encryption keys. Subsequent operations on the memory area storing secrets may allow the attacker to infer those secrets by observing side-channels – such as CPU cache accesses and power fluctuations.
The indirect branch predictor barrier (IBPB) was intended as a defense against Spectre v2 (CVE-2017-5715) attacks on x86 Intel and AMD chips. IBPB is designed to prevent forwarding of previously learned indirect branch target predictions for speculative execution.
[7]
Evidently, the barrier wasn't implemented properly.
"We found a microcode bug in the recent Intel microarchitectures – like Golden Cove and Raptor Cove, found in the 12th, 13th and 14th generations of Intel Core processors, and the 5th and 6th generations of Xeon processors – which retains branch predictions such that they may still be used after IBPB should have invalidated them," [8]explained Wikner. "Such post-barrier speculation allows an attacker to bypass security boundaries imposed by process contexts and virtual machines."
[9]Critical default credential bug in Kubernetes Image Builder allows SSH root access
[10]Critical hardcoded SolarWinds credential now exploited in the wild
[11]Microsoft crafts Rust hypervisor to power Azure workloads
[12]Manifest file destiny: Declare your funding needs via JSON
Wikner and Razavi also managed to leak arbitrary kernel memory from an unprivileged process on AMD silicon built with its Zen 2 architecture.
Videos of the [13]Intel and [14]AMD attacks have been posted, with all the cinematic dynamism one might expect from command line interaction.
Intel chips – including Intel Core 12th, 13th, and 14th generation and Xeon 5th and 6th – may be vulnerable. On AMD Zen 1(+) and Zen 2 hardware, the issue potentially affects Linux users.
[15]
The relevant details were disclosed in June 2024, but Intel and AMD found the problem independently.
Intel fixed the issue in a microcode patch ( [16]INTEL-SA-00982 ) released in March, 2024. Nonetheless, some Intel hardware may not have received that microcode update.
In their technical summary, Wikner and Razavi observe: "This microcode update was, however, not available in Ubuntu repositories at the time of writing this paper."
It appears Ubuntu has subsequently [17]dealt with the issue .
AMD issued its own advisory in November 2022, in security bulletin [18]AMD-SB-1040 . The firm notes that hypervisor and/or operating system vendors have work to do on their own mitigations.
"Because AMD’s issue was previously known and tracked under AMD-SB-1040, AMD considers the issue a software bug," the researchers explain. "We are currently working with the Linux kernel maintainers to merge our proposed software patch." ®
Get our [19]Tech Resources
[1] https://comsec.ethz.ch/breaking-the-barrier
[2] https://cloud.google.com/blog/topics/threat-intelligence/six-facts-about-address-space-layout-randomization-on-windows/
[3] https://meltdownattack.com/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZxKGJe8-7pcEO11KTVUrIQAAAIo&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZxKGJe8-7pcEO11KTVUrIQAAAIo&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZxKGJe8-7pcEO11KTVUrIQAAAIo&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZxKGJe8-7pcEO11KTVUrIQAAAIo&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://gist.github.com/sktt/3245f1c0727e45584077f6702c291102
[9] https://www.theregister.com/2024/10/16/critical_kubernetes_image_builder_bug/
[10] https://www.theregister.com/2024/10/16/solarwinds_critical_hardcoded_credential_bug/
[11] https://www.theregister.com/2024/10/17/microsoft_preps_rust_hypervisor_for/
[12] https://www.theregister.com/2024/10/17/zerodha_open_source_fund/
[13] https://www.youtube.com/watch?v=VYEVcj-vnbs
[14] https://www.youtube.com/watch?v=eODoOyhqtaQ
[15] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZxKGJe8-7pcEO11KTVUrIQAAAIo&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[16] https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00982.html
[17] https://ubuntu.com/security/CVE-2023-38575
[18] https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1040.html
[19] https://whitepapers.theregister.com/
Johannes Wikner and Kaveh Razavi of Swiss university ETH Zurich on Friday [1]published details about a cross-process Spectre attack that derandomizes [2]Address Space Layout Randomization and leaks the hash of the root password from the Set User ID (suid) process on recent Intel processors. The researchers claim they successfully conducted such an attack.
[3]Spectre refers to a set of attacks made possible because of the way processors conduct speculative execution - a performance optimization technique that involves making calculations in advance. The results can be used if needed, or otherwise discarded.
[4]
Branch prediction is a form of speculative execution, and modern processors use it to make guesses about the path a program will take. It's related to branch target prediction, which attempts to predict the target address of the next instruction to be executed in a given branch.
[5]
[6]
Spectre attacks try to make the branch predictor forward an incorrect prediction – such that when the processor executes the associated instructions, it accesses out-of-bounds memory that contains secrets like passwords or encryption keys. Subsequent operations on the memory area storing secrets may allow the attacker to infer those secrets by observing side-channels – such as CPU cache accesses and power fluctuations.
The indirect branch predictor barrier (IBPB) was intended as a defense against Spectre v2 (CVE-2017-5715) attacks on x86 Intel and AMD chips. IBPB is designed to prevent forwarding of previously learned indirect branch target predictions for speculative execution.
[7]
Evidently, the barrier wasn't implemented properly.
"We found a microcode bug in the recent Intel microarchitectures – like Golden Cove and Raptor Cove, found in the 12th, 13th and 14th generations of Intel Core processors, and the 5th and 6th generations of Xeon processors – which retains branch predictions such that they may still be used after IBPB should have invalidated them," [8]explained Wikner. "Such post-barrier speculation allows an attacker to bypass security boundaries imposed by process contexts and virtual machines."
[9]Critical default credential bug in Kubernetes Image Builder allows SSH root access
[10]Critical hardcoded SolarWinds credential now exploited in the wild
[11]Microsoft crafts Rust hypervisor to power Azure workloads
[12]Manifest file destiny: Declare your funding needs via JSON
Wikner and Razavi also managed to leak arbitrary kernel memory from an unprivileged process on AMD silicon built with its Zen 2 architecture.
Videos of the [13]Intel and [14]AMD attacks have been posted, with all the cinematic dynamism one might expect from command line interaction.
Intel chips – including Intel Core 12th, 13th, and 14th generation and Xeon 5th and 6th – may be vulnerable. On AMD Zen 1(+) and Zen 2 hardware, the issue potentially affects Linux users.
[15]
The relevant details were disclosed in June 2024, but Intel and AMD found the problem independently.
Intel fixed the issue in a microcode patch ( [16]INTEL-SA-00982 ) released in March, 2024. Nonetheless, some Intel hardware may not have received that microcode update.
In their technical summary, Wikner and Razavi observe: "This microcode update was, however, not available in Ubuntu repositories at the time of writing this paper."
It appears Ubuntu has subsequently [17]dealt with the issue .
AMD issued its own advisory in November 2022, in security bulletin [18]AMD-SB-1040 . The firm notes that hypervisor and/or operating system vendors have work to do on their own mitigations.
"Because AMD’s issue was previously known and tracked under AMD-SB-1040, AMD considers the issue a software bug," the researchers explain. "We are currently working with the Linux kernel maintainers to merge our proposed software patch." ®
Get our [19]Tech Resources
[1] https://comsec.ethz.ch/breaking-the-barrier
[2] https://cloud.google.com/blog/topics/threat-intelligence/six-facts-about-address-space-layout-randomization-on-windows/
[3] https://meltdownattack.com/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZxKGJe8-7pcEO11KTVUrIQAAAIo&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZxKGJe8-7pcEO11KTVUrIQAAAIo&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZxKGJe8-7pcEO11KTVUrIQAAAIo&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZxKGJe8-7pcEO11KTVUrIQAAAIo&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://gist.github.com/sktt/3245f1c0727e45584077f6702c291102
[9] https://www.theregister.com/2024/10/16/critical_kubernetes_image_builder_bug/
[10] https://www.theregister.com/2024/10/16/solarwinds_critical_hardcoded_credential_bug/
[11] https://www.theregister.com/2024/10/17/microsoft_preps_rust_hypervisor_for/
[12] https://www.theregister.com/2024/10/17/zerodha_open_source_fund/
[13] https://www.youtube.com/watch?v=VYEVcj-vnbs
[14] https://www.youtube.com/watch?v=eODoOyhqtaQ
[15] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZxKGJe8-7pcEO11KTVUrIQAAAIo&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[16] https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00982.html
[17] https://ubuntu.com/security/CVE-2023-38575
[18] https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1040.html
[19] https://whitepapers.theregister.com/
abend0c4
It's a reasonable point, but (at least so far) we're talking about the exfiltration of relatively small amounts of high-value data. There are already other ways to deal with these (TPM, HSM, etc). If it gets to the point where it's feasible to exfiltrate large amounts of data, you wouldn't want any of it in a less-secure environment. We've kind of got used to the idea of all-or-nothing security (eg "root"), but we're going to need multiple layers beyond those we already have, though the some of the initial attempts at secure enclaves and the like have not been a promising start.
And this is the reason why Win11 drops older processors
williamyf
Most likely Intel and/or AMD will no develop fixes like this for processors older than 8th gen, or Zen2 (respectively).
Ditto for drivers for other parts of their SoCs (nee processors).
Basically, when Microsoft meet with Intel and AMD and said ¿For which processors could you guarantee driver and microcode updates for the 10 year life of a "Win11" OS?, the answer was what we know now.
All the 7th gen and Zen+ exceptions, were oneoffs negotiated between the HW maker and intel/AMD
And I am guessing something similar will happen withy Win12, the Processor gen supported will be decided by the processor makers themselves, by denying support (Microcode and driver updates) to older gen processors.
I think it is time to give up on security for Performance cores and add some dedicated in-order non-speculative execution Secure cores to CPUs for all tasks that need to be done securely.
General purpose cores had a good run but I think their time is over what with them now already being split into Performance and Efficiency cores, in addition to having an increasing number of dedication accelerators for different tasks. Apple even put dedicated JavaScript accelerators on their CPUs.
We already have Performance cores, Efficiently cores, and a whole bunch of application specific cores, so why not off-load secure computing too?