Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

media.defcon.org

Post reply on HN
Print view View original

21–30 of 35 posts

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#21

Post by jandrese »

cesarb wrote: post #20
jandrese wrote: post #8

Sometimes it's nice to see SMP causing headaches for the "bad" guys for a change. They did eventually work around it, but half of this paper is working around problems where the second core gets out of sync and crashes as soon as they tried to exploit the system.

The most interesting part, to me, was that entering SMM pauses all cores at once, instead of doing the work in a single core like normal interrupts. That sounds like a performance killer, and I hope entering SMM is really rare in modern systems.

My information is pretty out of date, but when TPMs first arrived on the scene there was a fair bit of talk about using them as secure enclaves where you could do honest to god "trusted computing" with a fully verified stack on ordinary PC hardware. This largely didn't work out because TPMs were slow and every time you tried to do it you basically stalled out the rest of the machine, so once execution came back to the CPU everything was out of sync and all of the attached hardware like network cards and video cards crashed or froze. TPMs ended up only being useful as a place to store keys and occasionally cryptographically sign small amounts of data.

That said, the SMM can probably be a little less intrusive if it needs to be. Like it doesn't have to freeze the cores if all it is doing is reading your bitcoin addresses and passphrase out of memory, just stalling the memory bus for a moment or two.

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#22

Post by RockRobotRock »

HowardStark wrote: post #4

Is the recorded session available anywhere? Generally prefer the slides with the presenter walking us through them.

magnet:?xt=urn:btih:6b0c446541294d6b4ac0cfd6cdedf48e20034ad4&dn=defcon-talks&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Fopen.tracker.cl%3A1337%2Fannounce&tr=udp%3A%2F%2Fopen.demonii.com%3A1337%2Fannounce&tr=udp%3A%2F%2Fopen.stealth.si%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#23

Post by edelbitter »

pella wrote: post #3

AMD fix status: https://www.amd.com/en/resources/product-security/bulletin/a... https://ubuntu.com/security/CVE-2023-31315

> Please refer to your OEM for the BIOS update specific to your product.

Unless running hardware also used by powerful hosting providers (some of which care for security), these mitigation will not reach many systems. Checked a few "client" samples, seems like MSI has provided updated binary blobs, ASRock has provided some, Gigabyte has provided broken ones first and then backdated the new ones, ASUS (ROG/RUF/CSM) and Biostar customers are still waiting.

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#24

Post by ein0p »

jandrese wrote: post #8

Sometimes it's nice to see SMP causing headaches for the "bad" guys for a change. They did eventually work around it, but half of this paper is working around problems where the second core gets out of sync and crashes as soon as they tried to exploit the system.

These aren’t the “bad” guys. The “bad” guys are the people who put that backdoor in, deliberately or through lack of oversight.

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#25

Post by numpad0 »

BearOso wrote: post #12
kaoD wrote: post #9

Earlier quoted context omitted.

Wait, there are negative rings!? I'd like to learn more about this but it's not a very easy to search term. Any pointers?

I can't imagine it's a standard thing. On X86 we have ring 0 and 3, with 1 and 2 never used and removed in newer CPUs. ARM has 3 or 4 privilege layers, but they're named differently. They probably just called it ring -2 because it's a couple layers below ring 0.

Existing supervisors use 0, so when x86 virtualization was invented they added -1 for hypervisors. and so... are the monitors running on ring -2 ultravisors?

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#26

Post by colejohnson66 »

BearOso wrote: post #12
kaoD wrote: post #9

Earlier quoted context omitted.

Wait, there are negative rings!? I'd like to learn more about this but it's not a very easy to search term. Any pointers?

I can't imagine it's a standard thing. On X86 we have ring 0 and 3, with 1 and 2 never used and removed in newer CPUs. ARM has 3 or 4 privilege layers, but they're named differently. They probably just called it ring -2 because it's a couple layers below ring 0.

Rings 1 and 2 are still very much present in your desktop x86 machine; Your OS just doesn't use them. X86-S will remove them, but no CPUs implement that reduced architecture, and Intel has made no public announcements about future generations that will.

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#27

Post by [deleted] »

colejohnson66 wrote: post #26
BearOso wrote: post #12

Earlier quoted context omitted.

I can't imagine it's a standard thing. On X86 we have ring 0 and 3, with 1 and 2 never used and removed in newer CPUs. ARM has 3 or 4 privilege layers, but they're named differently. They probably just called it ring -2 because it's a couple layers below ring 0.

Rings 1 and 2 are still very much present in your desktop x86 machine; Your OS just doesn't use them. X86-S will remove them, but no CPUs implement that reduced architecture, and Intel has made no public announcements about future generations that will.

[deleted]

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#28

Post by aftbit »

edelbitter wrote: post #23
pella wrote: post #3

AMD fix status: https://www.amd.com/en/resources/product-security/bulletin/a... https://ubuntu.com/security/CVE-2023-31315

> Please refer to your OEM for the BIOS update specific to your product. Unless running hardware also used by powerful hosting providers (some of which care for security), these mitigation will not reach many systems. Checked a few "client" samples, seems like MSI has provided updated binary blobs, ASRock has provided some, Gigabyte has provided broken ones first and then backdated the new ones, ASUS (ROG/RUF/CSM) an…

So wait, is this fixed in BIOS or microcode?

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#29

Post by Taniwha »

The paper asks "why does this feature exist?" - probably they haven't gone far enough back in history (note I've worked on x86 clones I understand this stuff in far too great a detail)

Originally on x86 systems memory was in VERY short supply - SMM mode memory was the DRAM that the VGA window in low memory (0xa0000) overlaid - normal code couldn't access it because the video card claimed memory accesses to that range of addresses - so the north bridge when the CPU was in SMM mode switched data and instruction accesses to that range to go to DRAM rather than the VGA card .... that's great except remember that SMM mode was used for special setup stuff for laptops .... sometimes they need to be able to display on the screen .... that's what this special mode was originally for: so that SMM mode code can display on the screen (it's also likely why SMM mode graphics were so primitive, you're switching in and out of this mode for every pixel you write)

Re: DEF Con 32 – AMD Sinkclose Universal Ring-2 Privilege Escalation (Not Redacted) [pdf]

#30

Post by dwoldrich »

ngneer wrote: post #17
kaoD wrote: post #9

Earlier quoted context omitted.

Wait, there are negative rings!? I'd like to learn more about this but it's not a very easy to search term. Any pointers?

Just terminology. Whenever a new higher-privileged entity is created, it is sometimes described as a negative ring. There was a time when people thought if we could put the secure code in a lower ring, then with it we could protect the rest of the system. With virtualization, the hypervisor is in ring -1, which is technically not a ring, but rather a mode called VMX root operation, post-VMXON. This enables things lik…

Crazy complexity. Mind blown!
Post reply on HN