https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
A fundamental design flaw in Intel’s processor chips related to virtual memory system (Intel x86-64 hardware) allows normal user programs (even JavaScript in web browsers) to discern to some extent the layout or contents of protected kernel memory areas.
It is understood the bug is present in modern Intel processors produced in the past decade. It appears a microcode update can’t address it, so it has to be fixed in software at the OS level. This has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug, which is expected to cause 5 to 30 per cent slow down of your computer on next update!
Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in an upcoming Patch Tuesday. Patches for the Linux kernel are available. Apple’s 64-bit macOS, will also need to be updated.
This is bad news for Intel. Last year they had AMT vulnerability remote exploit and now this new blow in Intel security. I don’t think that computer buyers like that their computers become slower!
Details of the vulnerability within Intel’s silicon are under wraps and are expected to be released later this month – so follow the comments for updates.
565 Comments
Tomi Engdahl says:
Computer science researchers at the University of Virginia School of Engineering and University of California, San Diego, jointly published a paper outlining new Spectre variants that they say affect “billions” of AMD and Intel PCs.
Researchers find new CPU vulnerabilities and say fixes would kill performance
By Paul Lilly 1 day ago
https://www.pcgamer.com/researchers-find-new-cpu-vulnerabilities-and-say-fixes-would-kill-performance/?utm_source=facebook.com&utm_medium=social&utm_campaign=socialflow
The new Spectre variants leave billions of PCs defenseless, researchers say.
Update: In a statement provided to us, Intel refutes that the vulnerabilities outlined in the research paper are not addressed with existing patches and firmware updates.
“Intel reviewed the report and informed researchers that existing mitigations were not being bypassed and that this scenario is addressed in our secure coding guidance. Software following our guidance already have protections against incidental channels including the uop cache incidental channel. No new mitigations or guidance are needed,” Intel said.
Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations
https://software.intel.com/security-software-guidance/secure-coding/guidelines-mitigating-timing-side-channels-against-cryptographic-implementations
The primary concern with side channels is the protection of secrets. Secrets are broadly defined as any data that should not be seen or known by other users, applications, or even other code modules. When using side channel methods, malicious actors most commonly seek API keys, user passwords, or cryptographic keys because these may allow malicious actors to decrypt or access other protected secrets.
Tomi Engdahl says:
Researchers are claiming to have found a new type of Spectre attack that bypasses all existing protections, but that framing isn’t well supported.
Intel, Researchers Debate Whether New Spectre-Type Vulnerabilities Exist
https://www.extremetech.com/computing/322498-intel-researchers-debate-whether-new-spectre-type-vulnerabilities-exist?utm_campaign=trueAnthem%3A+Trending+Content&utm_medium=trueAnthem&utm_source=facebook
Over the past three days, reports of new Spectre-class attacks emerged that supposedly break all previous speculative execution patches and require performance-crippling mitigation techniques. There’s just one problem: Intel and the researchers fundamentally disagree as to whether a flaw exists at all.
The research team from the University of Virginia has written a paper arguing that there are catastrophic flaws in the way AMD and Intel currently implement micro-op caches that allow them to leak data under certain circumstances. Both Zen 2 and Skylake-class architectures are said to be vulnerable; the paper does not reference any testing done on Ice Lake, Tiger Lake, Rocket Lake, or Zen 3 processors.
Sounds pretty bad. The only problem is, Intel completely disagrees. The company’s official statement reads as follows:
Intel reviewed the report and informed researchers that existing mitigations were not being bypassed and that this scenario is addressed in our secure coding guidance. Software following our guidance already have protections against incidental channels, including the uop cache incidental channel. No new mitigations or guidance are needed.
Intel has released a number of patches for various flaws related to the initial Spectre/Meltdown disclosure back in 2018. It has also released its own writeups, reports, and documentation. However one feels about the existence of these issues, Intel appears to have engaged with the process of fixing them in good faith.
Over the past year, I’ve criticized several PR-driven security disclosures. In some cases, the histrionic tones of the press release and/or blog post have not matched the more measured claims in the paper itself. This is different. The research paper doesn’t catastrophize, but it presents the team’s findings as proof of an ongoing problem. According to Intel, that problem is addressed in existing guidance.
Tomi Engdahl says:
Researchers find new CPU vulnerabilities and say fixes would kill performance
By Paul Lilly 14 days ago
The new Spectre variants leave billions of PCs defenseless, researchers say.
https://www.pcgamer.com/researchers-find-new-cpu-vulnerabilities-and-say-fixes-would-kill-performance/?utm_source=facebook.com&utm_medium=social&utm_campaign=socialflow
Tomi Engdahl says:
Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations
https://software.intel.com/security-software-guidance/secure-coding/guidelines-mitigating-timing-side-channels-against-cryptographic-implementations
Tomi Engdahl says:
The Impact of Spectre and Meltdown on the Cloud
https://thenewstack.io/impact-spectre-meltdown-cloud/
This article will provide some basic framing for the issues. The focus here isn’t on the threats themselves, so much as what this new class of security vulnerability means, and how to start thinking about it as it pertains to your business, and your hosting environment in particular.
Meltdown is pretty bad, but we understand it and there are mitigations in place. By changing the operating system, we can create more determinism in how things run, and make sure that the vulnerability doesn’t exit. However, no one is happy with the fact that the mitigations can have significant performance implications.
‘Spectre’ & ‘Meltdown’ – What Cloud Users Need to Know
https://www.lightreading.com/enterprise-cloud/security-and-compliance/spectre-and-meltdown–andndash-what-cloud-users-need-to-know/a/d-id/739483
For enterprise cloud users worried about Spectre and Meltdown, there’s good news and bad news. The good news is that cloud users don’t have any special vulnerabilities compared with their legacy and consumer counterparts.
The bad news is that the cloud doesn’t provide any special protections either.
And cloud applications face special challenges due to the nature of how they operate and are consumed.
Spectre and Meltdown’s Critical Impact on Cloud Providers and Customers
https://www.serverwatch.com/server-news/spectre-and-meltdowns-critical-impact-on-cloud-providers-and-customers/
To put it bluntly, they are a huge deal for two key reasons. One is that the vulnerabilities could be exploited to steal sensitive data, and the other is because fixing the vulnerabilities will result in a reduction in the computing performance of the virtualized infrastructure that customers are paying for. Virtually Speaking
To address the first of these, the cloud computing giants have been working on the infrastructure that powers Amazon Web Services (AWS), Google Cloud Platform, and Microsoft Azure to make it secure.
For Amazon’s part, it says that all instances across the Amazon EC2 fleet have now been fixed, although new microcode supplied by Intel for its processors is causing instance and application crashes on occasion. To prevent this, Amazon is disabling some of the microcode and waiting for more Intel updates.
Google has also given an update on its Google Cloud Platform, stating that it has already been updated to prevent all known vulnerabilities. By using its VM Live Migration technology, Google was able to perform the updates with no forced maintenance windows or restarts.
What about Microsoft? Earlier in January, the company announced that “the majority of Azure infrastructure has already been updated to address this vulnerability. Some aspects of Azure are still being updated and require a reboot of customer VMs for the security update to take effect.”
What is Meltdown/Spectre?
https://www.cloudflare.com/learning/security/threats/meltdown-spectre/
Meltdown and Spectre are new processor vulnerabilities that affect most PCs and smartphones. There are patches available, but they affect processor performance.
Spectre, Meltdown and the Cloud
https://www.cloudwards.net/spectre-meltdown-and-the-cloud/
A Feature, Not a Bug
As it turns out, chips with this flaw have been turned out for close to 20 years now. Though the specifics are kept a bit vague and highly technical, most likely in an attempt to foil would-be hackers, what it boils down to is that the vulnerabilities lie in the design of the chips.
How the Cloud Is Affected by Spectre and Meltdown
With Meltdown affecting everything Intel going back decades as well as some ARM processors, and Spectre affecting, well, everything, the industry has gone in full overdrive putting together patches. At time of writing most computer systems have some kind of protections up (though not everyone is happy with the progress made).
So far, personal systems as well as some business ones are protected, or at least enough while bigger fixes are thought up. The same goes for cloud systems, but there are some more serious worries there. This has to do with the fact that more users make systems more susceptible to attack anyway, especially if they’re in the cloud where, theoretically, anyone can access them.
Another problem is that security risks in the cloud are a bigger deal than on a personal computer simply because servers have a lot more data run through them. Since most websites run on servers that host many other sites, a vulnerability in one is a vulnerability for all.
A third problem is that, because cloud systems are out there and need to be accessed by many people simultaneously (like with VPS hosting), the slowdowns that the current patches bring are a big problem. One example was a recent report in which game company Epic Games blamed some very bad lag issues its players experienced on the Meltdown patch.
The takeaway from all this is that cloud companies have an interesting few months or even years ahead of them as successive patches are rolled out.
Meltdown and Spectre: Case Analysis and Remediation for AWS Cloud
https://nutanix.medium.com/meltdown-and-spectre-case-analysis-and-remediation-for-aws-cloud-fc2c8510389b
Why do you need to be worried?
The vulnerability pretty much affects everyone and every computing device including laptops, desktops, tablets, smartphones and even cloud computing systems. The problem is magnified for cloud services such as Amazon’s Web Services, Microsoft Azure and Google’s Cloud Platform, due to the scale of their computing resources and the potential impact on performance of the fixes.
Below are the links where customers can read more about updates on patches from the leading public cloud providers and operating systems:
Security Advisory from AWS
Security Advisory from Microsoft Azure
Security Advisory from Google Cloud Platform (GCP)
Security Advisory from Heroku
Security Advisory from Ubuntu: To be announced
Security Advisory from Redhat
What should I do as an AWS Cloud user?
Immediate action is to update all your servers with suggested patches and reboot them to avoid this vulnerability.
5 steps to fix Meltdown and Spectre vulnerability in AWS environment
Plan your update
Backup your server data
Install patch as advised
Activate a Tech-QA team to verify if the servers are up and running gracefully as usual
Look for any other updates on same
The CPU catastrophe will hit hardest in the cloud
Cloud platforms have patched fast — but the hardest work is yet to come
https://www.theverge.com/2018/1/4/16850120/meltdown-spectre-vulnerability-cloud-aws-google-cpu
The Spectre attack is much more powerful in the cloud
Both Meltdown and Spectre deal with data leaking from one part of the computer to another, which makes them particularly dangerous when a single device is shared between users. With lots of commands running in parallel, the attacks found a way to extract data from the processor cache through a complex timing attack, sidestepping the usual privileges. Executed right, that could let a low-level process like a web plugin get access to passwords or other sensitive data held in a more secure part of your computer.
On a personal computer, that attack would be most useful for privilege escalation: a hacker running low-level malware could use a Spectre bug to own your whole computer. But there are already lots of ways to take over a computer once you’ve got a foothold, and it’s not clear how much a new processor attack would change things.
But privilege escalation is much scarier in the cloud, where the same server could be working for dozens of people at once. Platforms like Amazon Web Services and Google Cloud let online companies spread a single program across thousands of servers in data centers across the world, sharing hardware the same way you’d share an airplane or a subway car. Collective hardware isn’t a security problem because even when different users are on the same server, they’re in different software instances, with no way to jump from one instance to another. Spectre could change that, letting attackers steal data from anyone sharing the same chip. If a hacker wanted to perform that kind of attack, all they’d have to do is start their own instance and run the program.
Cloud services are also a lucrative target for anyone hoping to cash in on Spectre. Lots of midsize businesses run their entire infrastructure on AWS or Google Cloud, often trusting the platform with sensitive and potentially lucrative information.
So far, cloud platforms are taking the threat seriously, and doing everything they can to contain it. Amazon Web Services, Google Cloud, and Microsoft Azure all immediately deployed patches against the Meltdown attack, and there’s no indication that the available exploits could work against any of those platforms. Where there have been lingering vulnerabilities, it’s because companies are waiting on patches from third parties, like the Windows-based instances of Amazon EC2. The major platforms have handled the immediate response well, and there’s no reason to think we’re headed toward a cloud catastrophe in the days immediately to come.
What to do about Meltdown and Spectre in the Cloud: AWS, Azure and GCP
https://www.capside.com/labs/meltdown-and-spectre-in-the-cloud/
A design flaw present in most modern processors (including Intel, AMD and ARM) enables potential attackers to read areas of system memory that should have been inaccessible. Surely you have already heard and read plenty about Meltdown and Spectre, maybe even updated your computer just in case. But what about your Cloud infrastructure? Do you have to worry about Meltdown and Spectre in the Cloud?
If you have your critical platform in one of the leading Cloud providers (Amazon Web Services, Google Cloud Platform, Microsoft Azure), you might care about how to fix these vulnerabilities and how to ensure the performance of your platform. So do we. So here’s a brief clarification on how are we helping our clients ensuring their infrastructure.
Meltdown and Spectre in the Cloud
In environments where resources are shared among many clients, like public Clouds, this meant that guests could drill down into the underlying host’s physical memory, obtaining data from other clients.
This was initially managed following an industry best practice of responsible disclosure in which a vulnerability is publicly disclosed only after a period of time that allows for the vulnerability to be patched. Major operating systems, hardware and Cloud vendors signed an NDA and agreed upon a public disclosure date, January 9th.
Cloud vendors including Amazon Web Services, Google Cloud Platform and Microsoft Azure scheduled maintenances across their infrastructures and urged their clients to reboot certain resources. Unfortunately, the early and unexpected full disclosure of this issue moved them to speed up this process. In order to safeguard their clients’ security some pending actions had to be forced, causing some disruption.
There are two attack vectors:
infrastructure-based attacks originated in other guests of the same host
intra-guest attacks originated in software running in the guest instance
The first attack vector (infrastructure-based) was eliminated once the major public Cloud vendors patched their platform.
The solutions
Removing the second attack vector (intra-guest) will require Cloud clients to apply operating system and firmware updates, whenever they are released, which will require restarting a significant number of instances.
The fixes will involve outstanding changes to the kernel memory management and may take a toll on CPU performance, probably between 5 % and 30 %, as the latest figures show. This slowdown varies depending on factors like the rate of system calls.
Information for Google Cloud Customers on CPU Vulnerabilities
https://cloud.google.com/security/cpu-vulnerabilities
In 2017, Google’s Project Zero team discovered serious security flaws caused by “speculative execution,” a technique used by most modern processors (CPUs) to optimize performance. Independent researchers separately discovered and named these vulnerabilities “Spectre” and “Meltdown.”
Tomi Engdahl says:
Google Releases PoC Exploit for Browser-Based Spectre Attack
https://www.securityweek.com/google-releases-poc-exploit-browser-based-spectre-attack
Tomi Engdahl says:
Spectre exploits in the “wild”
https://dustri.org/b/spectre-exploits-in-the-wild.html
Someone was silly enough to upload a working spectre (CVE-2017-5753) exploit for Linux (there is also a Windows one with symbols that I didn’t look at.) on VirusTotal last month, so here is my quick Sunday afternoon lazy analysis.
The binary has its -h option stripped, likely behind a #define to avoid detection, but some of its parameters are obvious, like specifying what file to leak, or the kernel base address. The authors didn’t check (or care) that the logging function hasn’t been entirely optimized out, leaving a bunch of strings helping in the reversing process.
The exploit works in four stages:
Find the superblock,
Find the inode of the file to dump
Find the corresponding page address
Dumps the content of the file.
https://www.virustotal.com/gui/file/6461d0988c835e91eb534757a9fa3ab35afe010bec7d5406d4dfb30ea767a62c/detection
Tomi Engdahl says:
Researchers Break Intel SGX With New ‘SmashEx’ CPU Attack Technique https://thehackernews.com/2021/10/researchers-break-intel-sgx-with-new.html
A newly disclosed vulnerability affecting Intel processors could be abused by an adversary to gain access to sensitive information stored within enclaves and even run arbitrary code on vulnerable systems.
Tomi Engdahl says:
AMD Secure Memory Encryption Has a Flaw, Now Disabled by Default in Linux Kernel
By Aaron Klotz 3 days ago
AMD SME was causing boot failures on some devices
https://www.tomshardware.com/news/amd-memory-encryption-disabled-in-linux
Tomi Engdahl says:
AMD Secure Memory Encryption Has a Flaw, Now Disabled by Default in Linux Kernel
AMD SME was causing boot failures on some devices
https://www.tomshardware.com/news/amd-memory-encryption-disabled-in-linux
According to a report from Phoronix, the Linux 5.15 kernel is receiving a new fix that involves disabling AMD’s Secure Memory Encryption, or SME. This feature is normally enabled by default, but due to unexpected boot failures on some AMD machines, SME will now be disabled by default. Devs will update the Linux 5.15 kernel first, but the change will also move to prior kernels.
AMD Secure Memory Encryption is a feature exposed to AMD’s EPYC and Ryzen Pro processors that allows the CPUs to encrypt the memory at a hardware level. AMD says the feature offers no significant impact on system performance and works with any OS and application because it’s hardware-accelerated and doesn’t rely upon software.
Despite the benefits, the feature has caused bugs to appear in the Linux drivers with the interaction with the IOMMU and graphics drivers, causing Linux machines to fail at startup. Impacted systems also aren’t recognizing the encrypted RAM, particularly because some devices don’t have the correct Direct Memory Acces API or firmware to support the SMU.
Linux To No Longer Enable AMD SME Usage By Default Due To Problems With Some Hardware
https://www.phoronix.com/scan.php?page=news_item&px=Linux-SME-No-Default-Use
AMD –
Being sent in as a fix for the Linux 5.15 kernel this morning and to be back-ported to existing stable series is a behavior change that the Linux kernel will no longer use AMD Secure Memory Encryption (SME) by default on supported hardware but rather making it now opt-in due to shortcomings of some platforms.
Since the introduction of AMD SME support to the Linux kernel, Secure Memory Encryption has been activated by default when the SME support (AMD_MEM_ENCRYPT) is built into the kernel. That defaulting of “AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT” allowed for Secure Memory Encryption to be used out-of-the-box without needing to specify any extra kernel parameters or the like. Unfortunately, that’s led to boot failures on some platforms particularly around IOMMU along with other headaches to work out as well, like some graphics driver issues with not expecting the memory to be encrypted.
Tomi Engdahl says:
This bug doesn’t exist on x86: Exploiting an ARM-only race condition
How to exploit a double free and get a shell. “Use-After-Free for dummies”
https://github.com/stong/how-to-exploit-a-double-free
Tomi Engdahl says:
Kuuma ohjelmointikieli mullistaa Linuxia – Torvalds: “Voi olla osittain ratkaisu ongelmaan”
https://www.tivi.fi/uutiset/kuuma-ohjelmointikieli-mullistaa-linuxia-torvalds-voi-olla-osittain-ratkaisu-ongelmaan/5bf361e0-23df-4bd0-8a4e-0c770b72dc23
Linux täyttää 30 vuotta.
Rust kieli mahdollisesti käyttöön
Tomi Engdahl says:
CVE-2021-43267: Remote Linux Kernel Heap Overflow | TIPC Module Allows Arbitrary Code Execution
https://www.sentinelone.com/labs/tipc-remote-linux-kernel-heap-overflow-allows-arbitrary-code-execution/
Executive Summary
SentinelLabs has discovered a heap overflow vulnerability in the TIPC module of the Linux Kernel.
The vulnerability can be exploited either locally or remotely within a network to gain kernel privileges, allowing an attacker to compromise the entire system.
The TIPC module comes with all major Linux distributions but needs to be loaded in order to enable the protocol.
A patch has been released on the 29th of October and affects kernel versions between 5.10 and 5.15.
At this time, SentinelOne has not identified evidence of in-the-wild abuse.
Tomi Engdahl says:
Intel, AMD, Arm warn of new speculative execution CPU bugs https://www.bleepingcomputer.com/news/security/intel-amd-arm-warn-of-new-speculative-execution-cpu-bugs/
Security researchers have found new a new way to bypass existing hardware-based defenses for speculative execution in modern computer processors from Intel, AMD, and Arm. Today, the three CPU manufacturers have published advisories accompanied by mitigation updates and security recommendations to tackle recently discovered issues that allow leaking of sensitive information despite isolation-based protections. See also:
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html.
See also:
https://www.amd.com/system/files/documents/software-techniques-for-managing-speculation.pdf.
See also:
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/spectre-bhb
Tomi Engdahl says:
Intel CPUs Suffer Performance Hit From New Spectre-v2 Mitigations https://www.tomshardware.com/news/intel-cpus-performance-hit-spectre-v2-migitations
Branch History Injection (BHI), a new flavor of the Spectre-v2 vulnerability that affects both new and old Intel processors and specific Arm models, recently came to light. Linux publication Phoronix conducted testing that shows the new BHI mitigations could produce severe performance penalties up to 35%.
Tomi Engdahl says:
Academics Devise New Speculative Execution Attack Against Apple M1 Chips
https://www.securityweek.com/academics-devise-new-speculative-execution-attack-against-apple-m1-chips
A group of academic researchers has devised a new hardware attack that bypasses pointer authentication protections on Apple’s M1 processor.
Pointer authentication (PA) is a mechanism to prevent the modification of pointers in memory using a cryptographic hash, or pointer authentication code (PAC). With the integrity of a pointer verified against the PAC, a crash is triggered if the values do not match.
First introduced by ARM in 2017 and adopted by Apple in 2018, pointer authentication basically requires the attacker to guess the PAC of a pointer after modification to prevent triggering a crash when modifying code in memory.
Dubbed PACMAN, a new attack technique devised by a group of researchers at the Massachusetts Institute of Technology’s (MIT) Computer Science and Artificial Intelligence Laboratory (CSAIL) uses micro-architectural side-channels to leak PAC verification results and bypass PA without triggering a crash.
“[W]e propose the PACMAN attack, which extends speculative execution attacks to bypass Pointer Authentication by constructing a PAC oracle. Given a pointer in a victim execution context, a PAC oracle can be used to precisely distinguish between a correct PAC and an incorrect one without causing any crashes,” the researchers note in a paper.
PACMAN: Attacking ARM Pointer Authentication with
Speculative Execution
https://pacmanattack.com/paper.pdf
Tomi Engdahl says:
New ‘Hertzbleed’ Remote Side-Channel Attack Affects Intel, AMD Processors
https://www.securityweek.com/new-hertzbleed-remote-side-channel-attack-affects-intel-amd-processors
A team of academic researchers has identified a new side-channel method that can allow hackers to remotely extract sensitive information from a targeted system through a CPU timing attack.
Dubbed Hertzbleed, the new attack method was made public this week by researchers from the University of Texas at Austin, the University of Illinois Urbana-Champaign, and the University of Washington. In addition to a name, the attack has its own website and logo. A paper describing Hertzbleed is also available.
According to the researchers, Hertzbleed shows that power side-channel attacks can be turned into remote timing attacks, allowing attackers to obtain cryptographic keys from devices powered by Intel, AMD and possibly other processors.
In the past, researchers demonstrated CPU side-channel attacks that rely on observing variations in a processor’s power consumption.
Hertzbleed does not require any direct power measurement and instead relies on a feature called dynamic frequency scaling, which modern processors use to reduce power consumption.
“Under certain circumstances, periodic CPU frequency adjustments depend on the current CPU power consumption, and these adjustments directly translate to execution time differences (as 1 hertz = 1 cycle per second),” the researchers explained.
An analysis of these time differences can allow an attacker — in some cases even a remote attacker can observe the variations — to target cryptographic software and obtain valuable cryptographic keys.
The attack was demonstrated against SIKE, or Supersingular Isogeny Key Encapsulation, a post-quantum key encapsulation mechanism that is used by companies such as Microsoft and Cloudflare.
While Hertzbleed itself is not an actual vulnerability, two CVE identifiers did get assigned to it: CVE-2022-23823 and CVE-2022-24436.
https://www.hertzbleed.com/
Hertzbleed: Turning Power Side-Channel Attacks
Into Remote Timing Attacks on x86
https://www.hertzbleed.com/hertzbleed.pdf
Tomi Engdahl says:
by Sayan Sen — Several Intel CPUs from different generations have been found to be susceptible to new processor vulnerabilities related to MMIO Stale Data. Microsoft and Intel have published advisories about it.
https://lwn.net/Articles/898011/
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=441947019138
Processor MMIO Stale Data Vulnerabilities
+=========================================
+
+Processor MMIO Stale Data Vulnerabilities are a class of memory-mapped I/O
+(MMIO) vulnerabilities that can expose data. The sequences of operations for
+exposing data range from simple to very complex. Because most of the
+vulnerabilities require the attacker to have access to MMIO, many environments
+are not affected. System environments using virtualization where MMIO access is
+provided to untrusted guests may need mitigation. These vulnerabilities are
+not transient execution attacks. However, these vulnerabilities may propagate
+stale data into core fill buffers where the data can subsequently be inferred
+by an unmitigated transient execution attack. Mitigation for these
+vulnerabilities includes a combination of microcode update and software
+changes, depending on the platform and usage model. Some of these mitigations
+are similar to those used to mitigate Microarchitectural Data Sampling (MDS) or
+those used to mitigate Special Register Buffer Data Sampling (SRBDS).
Tomi Engdahl says:
Branch History Injection
On the Effectiveness of Hardware Mitigations Against Cross-Privilege Spectre-v2 Attacks
https://www.vusec.net/projects/bhi-spectre-bhb/
https://grsecurity.net/amd_branch_mispredictor_part_2_where_no_cpu_has_gone_before
Tomi Engdahl says:
Branch History Injection and Intra-mode Branch Target Injection / CVE-2022-0001, CVE-2022-0002 / INTEL-SA-00598
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html
https://www.amd.com/system/files/documents/software-techniques-for-managing-speculation.pdf
Tomi Engdahl says:
https://developer.arm.com/Arm%20Security%20Center/Speculative%20Processor%20Vulnerability
Tomi Engdahl says:
https://www.tomshardware.com/news/intel-cpus-performance-hit-spectre-v2-migitations
Tomi Engdahl says:
https://hackaday.com/2022/03/11/this-week-in-security-ddos-techniques-dirty-pipe-and-lapsus-continued/
Tomi Engdahl says:
https://www.fortinet.com/blog/threat-research/evolution-of-malware
Tomi Engdahl says:
Torvalds: Linux kernel team has sorted Retbleed chip flaw
But tidying things up has contributed to a one week delay on the version 5.19 release
https://www.theregister.com/2022/07/17/linux_5_19_rc7/
Tomi Engdahl says:
Linux x86 32-bit Is Vulnerable To Retbleed But Don’t Expect It To Get Fixed
https://www.phoronix.com/news/Linux-x86-Retbleed
Tomi Engdahl says:
New Spectre-type ‘Retbleed’ vulnerability drops. Will attackers use it?
https://www.scmagazine.com/analysis/threat-intelligence/new-spectre-type-retbleed-vulnerability-drops-will-attackers-use-it
Tomi Engdahl says:
Torvalds: Linux kernel team has sorted Retbleed chip flaw https://www.theregister.com/2022/07/17/linux_5_19_rc7/
Linux kernel developers have addressed the Retbleed speculative execution bug in older Intel and AMD silicon, but the fix wasn’t straightforward, so emperor penguin Linus Torvalds has delayed delivery of the next version by a week.
Tomi Engdahl says:
What’s Hertzbleed, and what’s so unique about it?
https://www.kaspersky.com/blog/hertzbleed-attack/44824/
In June, researchers from three US universities published a paper describing a actual attack that abuses the fact that CPU frequency changes depend on the load thereon (standard behavior for modern CPUs). CPU frequency is measured in hertz, hence the name Hertzbleed, hinting that a change in this frequency leads to data leakage. This method can be classified as a hardware attack; that is, one that exploits vulnerabilities or other specific weaknesses in hardware.
There are many attacks of this type, but almost all require direct access to the target computer or just a specific chip. But Hertzbleed can operate remotely!. The study is of great interest and, despite its complexity, can be summarized in layman’s terms. But for at least a basic understanding of its finer points, a bit of background knowledge is required. So we decided to do both: to post a simple explanation of Hertzbleed, and another slightly more complicated one (but still with no fancy graphs or abstruse calculations).
Tomi Engdahl says:
Retbleed
New Retbleed speculative execution CPU attack bypasses Retpoline fixes https://www.bleepingcomputer.com/news/security/new-retbleed-speculative-execution-cpu-attack-bypasses-retpoline-fixes/
Security researchers have discovered a new speculative execution attack called Retbleed that affects processors from both Intel and AMD and could be used to extract sensitive information. Retbleed focuses on return instructions, which are part of the retpoline software mitigation against the speculative execution class of attacks that became known starting early 2018, with Spectre. The issue impacts Intel Core CPUs from generation 6 (Skylake – 2015) through 8 (Coffee Lake – 2017) and AMD Zen 1, Zen 1+, Zen 2 released between 2017 and 2019. Alkup.
https://comsec.ethz.ch/wp-content/files/retbleed_sec22.pdf
New Spectre-type ‘Retbleed’ vulnerability drops. Will attackers use it?
https://www.scmagazine.com/analysis/threat-intelligence/new-spectre-type-retbleed-vulnerability-drops-will-attackers-use-it
Retbleed: Arbitrary Speculative Code Execution with Return Instructions https://comsec.ethz.ch/research/microarch/retbleed/
Retbleed (CVE-2022-29900 and CVE-2022-29901) is the new addition to the family of speculative execution attacks that exploit branch target injection to leak information, which we call Spectre-BTI. Unlike its siblings, who trigger harmful branch target speculation by exploiting indirect jumps or calls, Retbleed exploits return instructions. This means a great deal, since it undermines some of our current Spectre-BTI defenses.
Retbleed: New Speculative Execution Attack Targets Intel, AMD Processors: Researchers with ETH Zurich have devised a new speculative execution attack that undermines current Spectre defenses to leak information from Intel and AMD processors.
https://www.securityweek.com/retbleed-new-speculative-execution-attack-targets-intel-amd-processors
Herzbleed
What’s Hertzbleed, and what’s so unique about it?
https://www.kaspersky.com/blog/hertzbleed-attack/44824/
In June, researchers from three US universities published a paper describing a actual attack that abuses the fact that CPU frequency changes depend on the load thereon (standard behavior for modern CPUs). CPU frequency is measured in hertz, hence the name Hertzbleed, hinting that a change in this frequency leads to data leakage. This method can be classified as a hardware attack; that is, one that exploits vulnerabilities or other specific weaknesses in hardware.
There are many attacks of this type, but almost all require direct access to the target computer or just a specific chip. But Hertzbleed can operate remotely!. The study is of great interest and, despite its complexity, can be summarized in layman’s terms. But for at least a basic understanding of its finer points, a bit of background knowledge is required. So we decided to do both: to post a simple explanation of Hertzbleed, and another slightly more complicated one (but still with no fancy graphs or abstruse calculations).
Tomi Engdahl says:
ÆPIC Leak: Architectural Bug in Intel CPUs Exposes Protected Data
https://www.securityweek.com/aepic-leak-architectural-bug-intel-cpus-exposes-protected-data
A group of researchers from several universities and companies has disclosed a new Intel CPU attack method that could allow an attacker to obtain potentially sensitive information.
The research was conducted by researchers from the Sapienza University of Rome, the Graz University of Technology, the CISPA Helmholtz Center for Information Security, and Amazon Web Services.
The attack method has been dubbed AEPIC Leak — spelled ÆPIC Leak — and it’s related to the Advanced Programmable Interrupt Controller (APIC). This integrated CPU component is responsible for accepting, prioritizing, and dispatching interrupts to processors. When it’s in xAPIC mode, the APIC registers are accessed through a memory-mapped I/O (MMIO) page.
However, the researchers pointed out that unlike Meltdown and Spectre, which are transient execution attacks, AEPIC Leak exists due to an architectural bug, which leads to the disclosure of sensitive data without leveraging any side channel. They described it as “the first CPU bug able to architecturally disclose sensitive data.”
One of the researchers told SecurityWeek that since it does not rely on a side channel, the attack is extremely reliable.
“It is sufficient to load an enclave application in memory to be able to leak its contents. AEPIC Leaks can precisely target an application and fully dumps its memory in less than a second,” explained Pietro Borrello of the Sapienza University of Rome.
ÆPIC Leak, officially tracked as CVE-2022-21233, has been described as an uninitialized memory read issue that affects Intel CPUs.
Intel, which described it as a medium-severity issue related to improper isolation of shared resources, published an advisory on Tuesday and provided a list of impacted products.
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00657.html
Summary:
A potential security vulnerability in some Intel® Processors may allow information disclosure. Intel is releasing firmware updates to address this potential vulnerability.
Vulnerability Details:
CVEID: CVE-2022-21233
Description: Improper isolation of shared resources in some Intel(R) Processors may allow a privileged user to potentially enable information disclosure via local access.
CVSS Base Score: 6.0 Medium
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N
Affected Products:
Consult this list of affected products here.
Affected Processors: Transient Execution Attacks & Related Security Issues by CPU
https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
Tomi Engdahl says:
Architecturally Leaking Uninitialized Data from the Microarchitecture
https://aepicleak.com/
ÆPIC Leak is the first CPU bug able to architecturally disclose sensitive data. It leverages a vulnerability in recent Intel CPUs to leak secrets from the processor itself: on most 10th, 11th and 12th generation Intel CPUs the APIC MMIO undefined range incorrectly returns stale data from the cache hierarchy.
In contrast to transient execution attacks like Meltdown and Spectre, ÆPIC Leak is an architectural bug: the sensitive data gets directly disclosed without relying on any (noisy) side channel.
ÆPIC Leak is like an uninitialized memory read in the CPU itself.
A privileged attacker (Administrator or root) is required to access APIC MMIO. Thus, most systems are safe from ÆPIC Leak. However, systems relying on SGX to protect data from privileged attackers would be at risk, thus, have to be patched.
Tomi Engdahl says:
A research paper detailing ÆPIC Leak is available, as well as a dedicated website summarizing the findings. Proof-of-concept (PoC) exploit code has also been released.
https://aepicleak.com/
https://github.com/IAIK/AEPIC
Tomi Engdahl says:
AMD Processors Expose Sensitive Data to New ‘SQUIP’ Attack
https://www.securityweek.com/amd-processors-expose-sensitive-data-new-squip-attack
A group of academic researchers on Tuesday published a paper describing the first side-channel attack targeting the scheduler queues of modern processors.
Over the past years, researchers have demonstrated several CPU side-channel attacks that could allow attackers to obtain potentially sensitive information from memory. Some of these attacks rely on measuring contention, which is the conflict between multiple threads trying to use the same resource.
Superscalar processors rely on scheduler queues to decide the schedule of the instructions being executed. Intel CPUs have a single scheduler queue, but chips made by Apple and AMD have separate queues for each execution unit.
AMD processors also implement simultaneous multithreading (SMT), where a CPU core is split into multiple logical cores or hardware threads that execute independent instruction streams.
Researchers from the Graz University of Technology, the Georgia Institute of Technology, and the Lamarr Security Research non-profit research center discovered that an attacker on the same hardware core as the victim but in a different SMT thread can measure scheduler contention to obtain sensitive data. The attack method has been dubbed SQUIP (Scheduler Queue Usage via Interference Probing).
“An attacker running on the same host and CPU core as you could spy on which types of instructions you are executing due to the split-scheduler design on AMD CPUs.” Daniel Gruss, one of the Graz University of Technology researchers involved in the SQUIP project, explained in simple terms.
AMD was informed about the issue in December 2021 and assigned it the CVE identifier CVE-2021-46778 and a severity rating of ‘medium’. The chip giant published an advisory on Tuesday, informing customers that Zen 1, Zen 2 and Zen 3 microarchitectures are impacted.
The list of affected products includes Ryzen, Athlon and EPYC processors for desktops, workstations, mobile devices, Chromebooks, and servers.
While Intel and Apple products are currently not impacted, they have been notified as well.
While Apple also uses separate scheduler queues for its M1 processors — and likely also M2 — it has yet to introduce SMT, which means its current processors are not impacted.
SQUIP: Exploiting the Scheduler Queue Contention Side Channel
https://stefangast.eu/papers/squip.pdf
Execution Unit Scheduler Contention Side-Channel Vulnerability on AMD Processors
https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1039
Bulletin ID
AMD-SB-1039
Potential Impact
Information Disclosure
Severity
Medium
Summary
CVE-2021-46778
Execution unit scheduler contention may lead to a side channel vulnerability found on AMD CPU microarchitectures codenamed “Zen 1”, “Zen 2” and “Zen 3” that use simultaneous multithreading (SMT). By measuring the contention level on scheduler queues an attacker may potentially leak sensitive information.
Affected Products
Desktop
AMD Ryzen™ 2000 series Desktop processors
AMD Ryzen™ 3000 Series Desktop processors
AMD Ryzen™ 5000 Series Desktop processors
AMD Ryzen™ 4000 Series Desktop processors with Radeon™ graphics
AMD Ryzen™ 5000 Series Desktop processors with Radeon™ graphics
High-End Desktop (HEDT)
2nd Gen AMD Ryzen™ Threadripper™ processors
3rd Gen AMD Ryzen™ Threadripper™ processors
Workstation
AMD Ryzen™ Threadripper™ PRO processors
Mobile
AMD Athlon™ 3000 Series Mobile processors with Radeon™ graphics
AMD Ryzen™ 2000 Series Mobile processors
AMD Ryzen™ 3000 Series Mobile processors, 2nd Gen AMD Ryzen™ Mobile processors with Radeon™ graphics
AMD Ryzen™ 3000 Series Mobile processors with Radeon™ graphics
AMD Ryzen™ 4000 Series Mobile processors with Radeon™ graphics
AMD Ryzen™ 5000 Series Mobile processors with Radeon™ graphics
Chromebook
AMD Athlon™ 3000 Series Mobile processors with Radeon™ graphics
AMD Athlon™ Mobile processors with Radeon™ graphics
AMD Ryzen™ 3000 Series Mobile processors with Radeon™ graphics
Server
1st Gen AMD EPYC™ processors
2nd Gen AMD EPYC™ processors
3rd Gen AMD EPYC™ processors
Mitigation
AMD recommends software developers employ existing best practices1,2, including constant-time algorithms and avoiding secret-dependent control flows where appropriate to help mitigate this potential vulnerability.
Tomi Engdahl says:
Making Linux Kernel Exploit Cooking Harder https://security.googleblog.com/2022/08/making-linux-kernel-exploit-cooking.html
The Linux kernel is a key component for the security of the Internet.
Google uses Linux in almost everything, from the computers our employees use, to the products people around the world use daily like Chromebooks, Android on phones, cars, and TVs, and workloads on Google Cloud.. Because of this, we have heavily invested in Linuxs security – and today, were announcing how were building on those investments and increasing our rewards.
Tomi Engdahl says:
APIC/EPIC! Intel chips leak secrets even the kernel shouldnt see https://nakedsecurity.sophos.com/2022/08/10/apic-epic-intel-chips-leak-secrets-even-the-kernel-shouldnt-see/
Heres this weeks BWAIN, our jocular term for a Bug With An Impressive Name. BWAIN is an accolade that we hand out when a new cybersecurity flaw not only turns out to be interesting and important, but also turns up with its own logo, domain name and website. This one is dubbed ÆPIC Leak, a pun on the words APIC and EPIC. The former is short for Advanced Programmable Interrupt Controller, and the latter is simply the word epic, as in giant, massive, extreme, mega, humongous.
Tomi Engdahl says:
New Vulnerability Affects All AMD Zen CPUs: Threading May Need to Be Disabled
By Anton Shilov published 2 days ago
Side-channel SQUIP vulnerability affects all SMT-enabled Zen CPUs.
https://www.tomshardware.com/news/new-vulnerability-affects-all-amd-zen-cpus
Contemporary superscalar microprocessors with out-of-order execution use a number of ways to boost their performance. Simultaneous multi-threading (executing more than one threads of code on a CPU core) is one of the most efficient ways to improve processor performance.
Tomi Engdahl says:
AEPIC and SQUIP
https://hackaday.com/2022/08/12/this-week-in-security-breaches-aepic-squip-and-symbols/
Tomi Engdahl says:
‘DirtyCred’ Vulnerability Haunting Linux Kernel for 8 Years
https://www.securityweek.com/dirtycred-vulnerability-haunting-linux-kernel-8-years
Academic researchers from Northwestern University have shared details on ‘DirtyCred’, a previously unknown privilege escalation vulnerability affecting the Linux kernel.
Tracked as CVE-2022-2588, the security flaw can be exploited to escalate privileges, and can also lead to a container escape. The academics say the vulnerability has been present in Linux for eight years.
Described as a use-after-free in the cls_route filter implementation of the Linux kernel, the bug exists because an old filter is not removed from the hashtable before it is freed. The issue can be exploited by a local user with the CAP_NET_ADMIN capability and could lead to a system crash or arbitrary code execution.
PhD students Zhenpeng Lin and Yuhang Wu, and associate professor Xinyu Xing explained earlier this month during the Black Hat conference that the issue is similar to the Dirty Pipe vulnerability (CVE-2022-0847) impacting Linux kernel versions 5.8 and later.
What made Dirty Pipe reputable was its easy exploitation despite protections such as kernel address randomization and pointer integrity check, coupled with the fact that it could be exploited without modifications on all impacted kernel versions.
Tomi Engdahl says:
https://techcrunch.com/2022/09/14/microsoft-zero-day-windows/
Microsoft also released patches for a second zero-day flaw, tracked as CVE-2022-23960, which it describes as a cache speculation vulnerability known as “Spectre-BHB” affecting Windows 11 for ARM-based systems. Spectre-BHB is a variant of the Spectre v2 vulnerability, which can allow attackers to steal data from memory.
Arm: CVE-2022-23960 Cache Speculation Restriction Vulnerability
CVE-2022-23960
https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-23960
Tomi Engdahl says:
https://www.bleepingcomputer.com/news/microsoft/microsoft-releases-windows-security-updates-for-intel-cpu-flaws/
Tomi Engdahl says:
In this issue: A new tool helps find speculative leaks in commercial CPUs; Data Science Summer School; and a conversation on how AI can improve carbon sequestration: https://msft.it/61805SH58
Tomi Engdahl says:
Linux Will Stop Randomizing Per-CPU Entry Area When KASLR Is Not Active
https://www.phoronix.com/news/Linux-Random-Per-CPU-Entry-ASLR
With the Linux 6.2 release kernel developers addressed “a tasty target for attackers” after it was realized that the per-CPU entry data was not being randomized, even in the presence of Kernel Address Space Layout Randomization (KASLR). The per-CPU entry area randomization has been present since Linux 6.3 but then was realized it’s being activated even if KASLR was disabled, so now that is changing to avoid possible confusion.
It was recently realized that the x86_64 per-CPU entry area randomization is happening even if KASLR is disabled. Thus with this randomization always happening even if Kernel Address Space Layout Randomization is off could lead to confusion/issues by users/developers. In particular, when debugging the kernel, benchmarking and expecting deterministic results, and related scenarios where that added randomization isn’t desired.
Sent out today as part of the x86/urgent pull request as updates ahead of today’s Linux 6.3-rc4 release is the fix to only randomize the per-CPU entry area when KASLR is enabled.
That patch is also marked for back-porting, so it should be appearing in the Linux 6.2 stable series soon
Tomi Engdahl says:
Intel CPUs vulnerable to new transient execution side-channel attack https://www.bleepingcomputer.com/news/security/intel-cpus-vulnerable-to-new-transient-execution-side-channel-attack/
A new side-channel attack impacting multiple generations of Intel CPUs has been discovered, allowing data to be leaked through the EFLAGS register. Instead of relying on the cache system like many other side-channel attacks, this new attack leverages a flaw in transient execution that makes it possible to extract secret data from user memory space through timing analysis. The attack works as a side channel to Meltdown, a critical security flaw discovered in 2018, impacting many x86-based microprocessors. Meltdown has been largely mitigated through software patches, microcode updates, and hardware redesigns; however, no solution has addressed the problem 100%, and the latest attack method might work even in fully patched systems depending on hardware, software, and patch configurations
Tomi Engdahl says:
Google Audit Finds Vulnerabilities in Intel TDX
https://www.securityweek.com/google-audit-finds-vulnerabilities-in-intel-tdx/
Over a nine-month audit, Google researchers identified ten security defects in Intel TDX, including nine vulnerabilities addressed with TDX code changes.
Google this week published the results of a nine-month audit of Intel Trust Domain Extensions (TDX), which resulted in the discovery of ten security defects.
Providing hardware isolated virtual machines, TDX has been added to some Intel Xeon Scalable CPUs to support confidential computing by isolating sensitive resources from the hosting environment.
Focused on identifying any vulnerabilities in Intel’s technology before it entered production, the security review was performed by a team of Google Cloud Security and Project Zero researchers, working together with Intel engineers.
The team identified 81 potential attack vectors and ten confirmed vulnerabilities. Nine of the defects were addressed in the TDX code, while the tenth issue required changes to the guide for writing a BIOS to support TDX. Intel also made five defense-in-depth changes.
The vulnerabilities, Google says, could lead to arbitrary code execution, cryptographic weaknesses, denial-of-service conditions, and weaknesses in debug or deployment facilities.
No CVE identifiers were issued for the discovered bugs, but Intel did assess their severity and assigned a CVSS score of 9.3 to an incorrect handling of interrupts when the Authenticated Code Module (ACM) transitioned from the privileged execution context to an untrusted context.
The flaw could be exploited to execute arbitrary code within the privileged ACM execution mode, compromising both TDX integrity and the security of any deployed virtual machines.
“The review met its expected goals and was able to ensure significant security issues were resolved before the final release of Intel TDX. Overall, the review provided Google with a better understanding of how the TDX feature functions which can be used to guide deployment,” Google says.
“Where possible the review performed variant analysis of any discovered issues to determine if the same pattern could be identified in other areas of the code base. All confirmed issues were mitigated before the production release of the 4th gen Intel Xeon Scalable processors,” Google explains in a detailed report (PDF).
https://services.google.com/fh/files/misc/intel_tdx_-_full_report_041423.pdf
Tomi Engdahl says:
Linux kernel logic allowed Spectre attack on ‘major cloud provider’
Kernel 6.2 ditched a useful defense against ghostly chip design flaw
https://www.theregister.com/2023/04/14/linux_kernel_spectre_flaw_fixed/
The Spectre vulnerability that has haunted hardware and software makers since 2018 continues to defy efforts to bury it.
On Thursday, Eduardo (sirdarckcat) Vela Nava, from Google’s product security response team, disclosed a Spectre-related flaw in version 6.2 of the Linux kernel.
The bug, designated medium severity, was initially reported to cloud service providers – those most likely to be affected – on December 31, 2022, and was patched in Linux on February 27, 2023.
Tomi Engdahl says:
New hardware vulnerability in Intel processors https://www.kaspersky.com/blog/transient-cpu-eflags/48229/
Researchers at both the University of Maryland in the U.S. and Tsinghua University in China have published a scientific paper documenting a new side-channel attack method that exploits a previously unknown hardware vulnerability in Intel processors.
Although the vulnerability seems to affect the chipmakers latest processors, its most effective in attacking older models that are also exposed to the Meltdown vulnerability
Researchers at both the University of Maryland in the U.S. and Tsinghua University in China have published a scientific paper documenting a new side-channel attack method that exploits a previously unknown hardware vulnerability in Intel processors. Although the vulnerability seems to affect the chipmaker’s latest processors, it’s most effective in attacking older models that are also exposed to the Meltdown vulnerability. The paper would likely be purely of scientific interest were it not for one aspect: attackers steal sensitive information by changing flag register data.
Timing the Transient Execution:
A New Side-Channel Attack on Intel CPUs
https://arxiv.org/pdf/2304.10877.pdf
n this work, we discover a vulnerability that the change of the
EFLAGS register in transient execution may have a side effect
on the Jcc (jump on condition code) instruction after it in Intel
CPUs. Based on our discovery, we propose a new side-channel
attack that leverages the timing of both transient execution and
Jcc instructions to deliver data. This attack encodes secret data
to the change of register which makes the execution time of
context slightly slower, which can be measured by the attacker
to decode data. This attack doesn’t rely on the cache system
and doesn’t need to reset the EFLAGS register manually to its
initial state before the attack, which may make it more difficult to
detect or mitigate. We implemented this side-channel on machines
with Intel Core i7-6700, i7-7700, and i9-10980XE CPUs. In the
first two processors, we combined it as the side-channel of the
Meltdown attack, which could achieve 100% success leaking rate.
We evaluate and discuss potential defenses against the attack. Our
contributions include discovering security vulnerabilities in the
implementation of Jcc instructions and EFLAGS register and
proposing a new side-channel attack that does not rely on the
cache system.
Tomi Engdahl says:
New hardware vulnerability in Intel processors
A brief, plain-language explanation of an advanced method of data theft using features of modern CPUs.
https://www.kaspersky.com/blog/transient-cpu-eflags/48229/
Tomi Engdahl says:
The bug can cause the chips to leak data at a rate of up to 30 kilobytes per core per second, according to some researchers.
Encryption-breaking, password-leaking bug in many AMD CPUs could take months to fix
“Zenbleed” bug affects all Zen 2-based Ryzen, Threadripper, and EPYC CPUs.
by Andrew Cunningham – Jul 25, 2023 6:31pm EET
https://arstechnica.com/information-technology/2023/07/encryption-breaking-password-leaking-bug-in-many-amd-cpus-could-take-months-to-fix/?utm_brand=ars&utm_source=facebook&utm_medium=social&utm_social-type=owned&fbclid=IwAR0n7gFzZVswDMUiLYNg5xsPdQPAS89ZzC3zNTxB45wWdC5pvtTnDXz1l8I
A recently disclosed bug in many of AMD’s newer consumer, workstation, and server processors can cause the chips to leak data at a rate of up to 30 kilobytes per core per second, writes Tavis Ormandy, a member of Google’s Project Zero security team. Executed properly, the so-called “Zenbleed” vulnerability (CVE-2023-20593) could give attackers access to encryption keys and root and user passwords, along with other sensitive data from any system using a CPU based on AMD’s Zen 2 architecture.
The bug allows attackers to swipe data from a CPU’s registers. Modern processors attempt to speed up operations by guessing what they’ll be asked to do next, called “speculative execution.” But sometimes the CPU guesses wrong; Zen 2 processors don’t properly recover from certain kinds of mispredictions, which is the bug that Zenbleed exploits to do its thing.
The bad news is that the exploit doesn’t require physical hardware access and can be triggered by loading JavaScript on a malicious website (according to networking company Cloudflare). The good news is that, at least for now, there don’t seem to be any cases of this bug being exploited in the wild yet, though this could change quickly now that the vulnerability has been disclosed, and the bug requires precise timing to exploit.
“AMD is not aware of any known exploit of the described vulnerability outside the research environment,” the company told Tom’s Hardware. Cloudflare also says there is “no evidence of the bug being exploited” on its servers.
Tomi Engdahl says:
“Tavis Ormandy, a researcher with Google Information Security, posted today about a new vulnerability he independently found in AMD’s Zen 2 processors. The ‘Zenbleed’ vulnerability spans the entire Zen 2 product stack, including AMD’s EPYC data center processors and the Ryzen 3000/4000/5000 CPUs, allowing the theft of protected information from the CPU, such as encryption keys and user logins. The attack does not require physical access to the computer or server and can even be executed via javascript on a webpage.” … “it will not patch its consumer Zen 2 Ryzen 3000, 4000, and some 5000-series chips until November and December of this year. AMD’s processors used in the PS5, Xbox Series X and S, and Steam Deck are all also powered by Zen 2 chips, but it remains unclear if those are impacted.”
AMD ‘Zenbleed’ Bug Leaks Data From Zen 2 Ryzen, EPYC CPUs: Most Patches Coming Q4 (Updated)
By Paul Alcorn published 6 days ago
A huge Zen 2 leak requires a patch.
https://www.tomshardware.com/news/zenbleed-bug-allows-data-theft-from-amds-zen-2-processors-patches-released?fbclid=IwAR29Px9K7kt5srHwWFWBrGboxBAOJl-4zLXrQjrDl1VeOR03GIxSrid7wNM