Researchers reveal "Sinkclose" vulnerability affecting nearly all AMD processors since 2006

Jimmy2x

Posts: 251   +29
Staff
What just happened? Security researchers at this year's Def Con have presented findings regarding a long-standing albeit recently discovered vulnerability in AMD processors called "Sinkclose." Though rather hard to exploit, the security flaw can potentially yield catastrophic results for any system unlucky enough to fall victim to it.

On Saturday, IOActive's Principal Security Consultant Enrique Nissim and Associate Principal Security Consultant Krzysztof Okupski delivered vulnerability research in a presentation titled AMD Sinkclose: Universal Ring-2 Privilege Escalation. According to the team's presentation, its team noticed a flaw in one of the components required to secure an execution mode known as System Management Mode. This mode provides attackers access to a highly versatile and powerful execution method. The exploit is invisible to OS-level protections such as anti-virus, anti-malware, and anti-cheat solutions commonly used in online gaming.

Exploiting the vulnerability is not easy (thankfully) and requires the attacker to gain access to the system's kernel first. If successful, the bad actor can use Ring-0 privileges to gain Ring-2 privileges to install an undetectable bootkit. Bootkits are malware designed to target a system's master boot record. Once installed, it cannot be easily detected or removed. In some cases, a successful attack can even persist despite a complete reinstallation of the OS. In these scenarios, an affected machine may require a complete replacement rather than typical malware removal and remediation.

Despite only being recently reported and tracked as CVE-2023-31315, the Sinkclose vulnerability appears to have been a long-standing issue that went undetected in many of AMD's workstations and server-class CPUs for the last 18 years. According to AMD's product security bulletin, the vulnerability impacts many processors across its data center CPUs, graphics solutions, embedded processors, desktops, HEDTs, workstations, and mobile product lines.

IOActive's researchers disclosed the issue to AMD 10 months before its announcement, giving the chipmaker time to review and address it before going public. Team Red already issued mitigations for EPYC and Ryzen CPUs. An AMD spokesperson told Wired that additional mitigations for embedded processors and other affected products would be coming soon. However, the company didn't provide an official timeline.

While the initial news and potential damage may sound horrific, users can rest easier knowing that the vulnerability went undetected for almost two decades, and it appears that hackers have never exploited it. Given AMD's remediation efforts and the inherent difficulty attackers would face in obtaining kernel-level access, widespread exploitation of the vulnerability is highly unlikely.

Permalink to story:

 
LOL; that sojnds way worse than current intel CPU issue....and far longer in terms of not being addressed.
 
Considering how difficult it is to exploit this flaw, that no one has used it and that AMD already patched it in March, what you are saying is complete non-sense.
It wasn't fully patched. Only the newer stuff was which is Ryzen and Epyc. Old procs still are vulnerable but nothing is likely going to happen. However, it was unknown for 20 years now it's known n not fully patched, means issues can still araise.

No one needs to worry in the end. AMD is aware and security people know what to look for. Nothing is ever fully safe.
 
"Exploiting the vulnerability is not easy and requires the attacker to gain access to the system's kernel first"
If an attacker gets access to kernel its game over no matter what cpu you are running.
So I wouldn't call that a cpu vulnerability
 
If an attacker gets access to kernel its game over no matter what cpu you are running.
So I wouldn't call that a cpu vulnerability
Then you're misunderstanding the issue. Every time you grant an install program or anything else admin privileges, you're granting it kernel access. Using this exploit, the code can further escalate to SMM -- system management mode. That allows the attacker to install bootkit code that is invisible to antivirus programs and persists even if the OS is wiped and reinstalled entirely. So, for instance, if the OEM who sold you your system first ran an infected diagnostic or benchmarking tool on the system before performing a fresh OS install, you might receive an infected system without your even knowing it ... and no amount of antiviral scans will flag your having it.
 
Then you're misunderstanding the issue. Every time you grant an install program or anything else admin privileges, you're granting it kernel access. Using this exploit, the code can further escalate to SMM -- system management mode. That allows the attacker to install bootkit code that is invisible to antivirus programs and persists even if the OS is wiped and reinstalled entirely. So, for instance, if the OEM who sold you your system first ran an infected diagnostic or benchmarking tool on the system before performing a fresh OS install, you might receive an infected system without your even knowing it ... and no amount of antiviral scans will flag your having it.
Bootkits are malware designed to target a system's master boot record.
How hard is it to wipe the MBR and who would trust a premade system ?
That would be a huge mistake.
A secure system cannot get infected by this, even if you get an OEM system,
boot linux live wipe MBR reboot and install windows. Problem solved.
Besides a system with OS preinstalled can have many security holes and should never be trusted.
 
Last edited:
Bootkits are malware designed to target a system's master boot record.
How hard is it to wipe the MBR and who would trust a premade system ?
That would be a huge mistake
Oops! Using this vulnerability, a bootkit can be installed within the UEFI firmware itself. Wipe the MBR all you want; you'll still be infected.
 
If the bootkit goes in the UEFI there are still solutions don't get crazy about it.
I remeber back in the spectre meltdown days, many ppl got crazy disabled MT used new bioses and stuff..I never updated windows never updated bios, unless I had a problem and never got infected.
 
"bad actor can use Ring-0 privileges to gain Ring-2 privileges to install an undetectable bootkit"
Somebody has no understanding of security rings, whatsoever...
 
"Exploiting the vulnerability is not easy and requires the attacker to gain access to the system's kernel first"
If an attacker gets access to kernel its game over no matter what cpu you are running.
So I wouldn't call that a cpu vulnerability

Yeah malware can already do all that in kernel mode, so what does the vulnerability do?
 
LOL; that sojnds way worse than current intel CPU issue....and far longer in terms of not being addressed.
More like case of researching computer science for the sake of computer science. Or someone is playing shorting another big tech company.
Were You hoping to buy some discounted AMD shares, now that They are on top of the world in CPUs?
Sorry, that's a big boys game, the ones that can afford publish a scientific paper on CPUs historical vulnerability.
 
The article seems incorrect. It's not ring 2, as stated on the AMD website, the vector resides at the lowest level "Ring 0", don't give junk software access to your PC's kernel and you'll be fine.

This shouldn't even be considered a vulnerability, giving access to ring 0 is like handing over your bank account password.

**"Improper validation in a model specific register (MSR) could allow a malicious program with ring0 access to modify SMM configuration while SMI lock is enabled," -> https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7014.html
 
"bad actor can use Ring-0 privileges to gain Ring-2 privileges to install an undetectable bootkit"
Somebody has no understanding of security rings, whatsoever...
No, the article is correct, though the typography is flawed. It should read "...can use Ring 0 privileges to gain Ring negative 2 privileges...."

Yeah malware can already do all that in kernel mode, so what does the vulnerability do?
Malware cannot enter SMM mode in Ring 0 and override an SMI lock to modify the UEFI firmware.

This shouldn't even be considered a vulnerability, giving access to ring 0 is like handing over your bank account password.
Despite the misleading graphic in the article, there are protection rings below zero.
 
Another 'exploit' where the hack requires Ring 0 privileges to get into the system...
If you have Ring 0 you can basically do anything so I really don't call this a vulnerability at all. Its interesting as it can hide away but getting it on there is far from straightforward.
 
Reading through AMD's bulletin page, they've released updated microcode for almost everything affected, with only embedded systems awaiting an update (Oct 2024).

The only notable exception is the Ryzen 3000 series, where they're saying they are not planning to fix. As an owner of a system with a 3900X, it would be nice to see them implement a fix here also, but I guess worse case scenario is re-flash the BIOS and wipe the drives if I suspect I've stupidly let an unknown program access the kernel.
 
As an owner of a system with a 3900X, it would be nice to see them implement a fix here also, but I guess worse case scenario is re-flash the BIOS and wipe the drives if I suspect I've stupidly let an unknown program access the kernel.
It's not so simple. A UEFI-based bootkit will run the moment your machine is powered-on. Some of these (like some CosmicStrand variants) instantly go resident and infect the EFI on every drive they see. The moment you reflash your UEFI, you're instantly reinfected.

And for those people who believe that this exploit hasn't been already used simply because no one's noticed it, I'll remind you that rootkits like CosmicStrand were in the wild for six full years before being detected.

If you have Ring 0 you can basically do anything so I really don't call this a vulnerability at all.
Sigh, once again -- you cannot "do anything" with Ring 0. The entire rationale behind protection rings below zero is because it is indeed limited.
 
Reading through AMD's bulletin page, they've released updated microcode for almost everything affected, with only embedded systems awaiting an update (Oct 2024).

The only notable exception is the Ryzen 3000 series, where they're saying they are not planning to fix. As an owner of a system with a 3900X, it would be nice to see them implement a fix here also, but I guess worse case scenario is re-flash the BIOS and wipe the drives if I suspect I've stupidly let an unknown program access the kernel.

AMD should be ashamed of themselves for not fixing 3000 series. They should fix all the Ryzen chips. I understand now fixing chips from 2006, but come on AMD. Seriously?!?!
 
It's not so simple. A UEFI-based bootkit will run the moment your machine is powered-on. Some of these (like some CosmicStrand variants) instantly go resident and infect the EFI on every drive they see. The moment you reflash your UEFI, you're instantly reinfected.

And for those people who believe that this exploit hasn't been already used simply because no one's noticed it, I'll remind you that rootkits like CosmicStrand were in the wild for six full years before being detected.

Sigh, once again -- you cannot "do anything" with Ring 0. The entire rationale behind protection rings below zero is because it is indeed limited.

Why can't you have a discussion without putting childish things like 'sigh' and 'I'll just get my popcorn' in your answers? Every post you submit is always confrontational, patronising and irritating.

I'm a developer and have been writing code on windows as well as embedded systems programming in a mix of assembler/c/c++ for 40 years. Writing device drivers requires an understanding of the CPL levels and how they equate to the coding of the hardware and there is no true level below zero (ignoring JTAG probe mode which isn't used in normal operations). The hardware instructions on the CPU can be coded to allow/restrict operations based on the ring you are in, but if you are executing at level 0 you can basically enable/override everything above and so access the hardware directly - this has to be the case for an operating system to function - there has to be some final arbiter and privilege level at which you have full control. If you are referring to the negative rings they are not real privilege levels but are used for things like VT and ME stuff - this is slightly different from the 'normal' execution of code on the OS.

Just been digging about for details - here's a good and much clearer and more thorough explanation than I can give on StackExchange.

 
No, the article is correct, though the typography is flawed.
So, the article is actually incorrect, and whoever wrote that had apparently no (or an incorrect) understanding of security rings. Thanks for confirming that.

Despite the misleading graphic in the article, there are protection rings below zero.
So, the article is actually incorrect, and whoever wrote that had apparently no (or an incorrect) understanding of security rings. Thanks for confirming that.
 
I'm a developer and have been writing code on windows as well as embedded systems programming in a mix of assembler/c/c++ for 40 years.
Appeal to authority noted. You're still wrong. Your link correctly notes that SMM and other negative rings aren't "true" rings. However, that in no way implies "if you're in Ring 0, you can basically do what you want." If this were true, the exploit in the article wouldn't exist -- as any "40 year experienced developer" could simply write a small program to alter UEFI firmware regardless.

if you are executing at level 0 you can basically enable/override everything above and so access the hardware directly
Again: you cannot "basically" enable SMM mode. Even from Ring 0, SMM can **only** be entered through a SMI hardware interrupt from the chipset. Furthermore, even if you're running at Ring 0 at the time, and have installed your own SMI driver:

"Immediately after SMI is triggered, the entry routine demotes the system to execute under CPL3 (least privileged level) before executing any third party SMI handlers. From [this privilege level] , MSR, IO, and supervisor pages access, critical register changes such as CR3, as well as privileged instructions such as “hlt” and “cli” all end up as General Protection Fault enforced by CPU hardware...."


Now, if you wish to continue arguing a clearly false position, I invite you to simply post the code showing us all -- including Microsoft, AMD, and Intel, how you can simply enter SMM mode from kernel mode, and write to the UEFI firmware at will.

Every post you submit is always confrontational, patronising and irritating.
Not every post, no. Only when a poster fails to read the article and prior posts, to reiterate already debunked statements.
 
Back