[HN Gopher] DEF Con 32 - AMD Sinkclose Universal Ring-2 Privileg...
___________________________________________________________________
DEF Con 32 - AMD Sinkclose Universal Ring-2 Privilege Escalation
(Not Redacted) [pdf]
Author : ruik
Score : 176 points
Date : 2024-09-07 19:44 UTC (5 days ago)
(HTM) web link (media.defcon.org)
(TXT) w3m dump (media.defcon.org)
| tux3 wrote:
| I was confused by the title, by "Ring-2" it means "Ring -2"
| (minus two), which is "traditionally" SMM (System Management
| Mode), a horrible relic that lets your BIOS/UEFI silently steal
| the CPU from the OS to implement janky drivers or workarounds
| directly in the firmware (occasionally causing all sorts of
| mayhem).
|
| (Actual Ring 2 is very rarely seen, so perhaps I should have
| known!)
| kaoD wrote:
| 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?
| veltas wrote:
| It's called System Management Mode, it's in official Intel
| documentation for x86.
| BearOso wrote:
| 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.
| okanat wrote:
| Ring -1 is the host system / virtual machine manager when
| the ring 0 OS is running as a VM. Ring -2 is more
| privileged than that since it can interrupt Ring -1 and can
| affect the execution of VM instructions.
| adrian_b wrote:
| Arm (Aarch64) Exception Level 0 corresponds to Ring 3 of
| x86.
|
| Arm (Aarch64) Exception Level 1 corresponds to Ring 0 of
| x86.
|
| Arm (Aarch64) Exception Level 2 corresponds to the
| Hypervisor level a.k.a. Ring -1 of x86.
|
| Arm (Aarch64) Exception Level 3 corresponds to the System
| Management Mode a.k.a. Ring -2 of x86.
|
| Fortunately, in Arm EL3 the same instruction set is used as
| in any other level, unlike in x86, where SMM uses the
| obsolete 16-bit 8086 ISA, so for compiling programs that
| will be executed in SMM you have to use a special tool set.
|
| Unfortunately, both the Arm EL3 and the x86 SMM allow the
| manufacturers of computing devices to do things that are
| either stupid or in direct contradiction with the interests
| of the owners of the devices and the owners may not be able
| to do anything to correct this, unless they can exploit
| vulnerabilities like the one that has now been patched by
| AMD.
|
| There are no valid arguments for the existence of SMM and
| EL3 and the fact that they are not forbidden by law is a
| disgrace for the computing industry.
|
| Arm EL3 has been created as an imitation of the Intel SMM.
| The Intel SMM has been created because Microsoft was too
| lazy to introduce the required power management functions
| in the Windows and MS-DOS operating systems, so they passed
| the task to the motherboard or laptop manufacturers, for
| which Intel has provided SMM, to enable this.
| numpad0 wrote:
| Existing _super_ visors use 0, so when x86 virtualization
| was invented they added -1 for _hyper_ visors. and so...
| are the monitors running on ring -2 _ultra_ visors?
| colejohnson66 wrote:
| 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.
| hypeatei wrote:
| Good article on negative rings:
|
| https://medium.com/swlh/negative-rings-in-intel-
| architecture...
| dooglius wrote:
| I don't think there actually are, in the sense that there
| isn't a register somewhere with these values that gets
| compared against, the way there is with rings 0-3. I've only
| heard this in the context of reverse engineers describing the
| layers of access that undocumented parts of a modern CPU
| system have, I think it's just a made-up analogy. There is
| presumably some proprietary documentation out there with more
| official names.
| ngneer wrote:
| 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 like the blue pill attack, where the hypervisor is
| itself presented with a false image of the underlying
| physical hardware, by a malicious layer. You can find the
| same pattern in ARM TrustZone, where the secure code is
| repeatedly broken.
|
| "if only we had ring -N"
| pella wrote:
| AMD fix status: https://www.amd.com/en/resources/product-
| security/bulletin/a...
|
| https://ubuntu.com/security/CVE-2023-31315
| edelbitter wrote:
| > 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.
| HowardStark wrote:
| Is the recorded session available anywhere? Generally prefer the
| slides with the presenter walking us through them.
| colejohnson66 wrote:
| DEF CON recordings tend to take a while to appear. This one was
| supposedly recorded,[0] but I can't find it.
|
| [0]: https://info.defcon.org/event/?id=54863
| RockRobotRock wrote:
| magnet:?xt=urn:btih:6b0c446541294d6b4ac0cfd6cdedf48e20034ad4&dn
| =defcon-talks&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fan
| nounce&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.or
| g%3A451%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounc
| e
| jandrese wrote:
| 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.
| cesarb wrote:
| 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.
| jandrese wrote:
| 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.
| ein0p wrote:
| These aren't the "bad" guys. The "bad" guys are the people who
| put that backdoor in, deliberately or through lack of
| oversight.
| paulmd wrote:
| it's funny that they have to debunk the "root is root, why would
| AMD patch this" that goes around every time there's a serious
| issue that allows guest-root escape from virtualized containers.
|
| the same thing happened with the ryzenfall/masterkey exploit,
| where people were just in utter denial there was an actual
| exploit there, because root is root! People literally spent more
| time talking about who released it and their background image
| than the actual exploit. AMD obvious cannot have exploits, that's
| only an intel thing. /s
|
| _" alleged" flaws" (rolls eyes)
| https://old.reddit.com/r/Amd/comments/845w8e/alleged_amd_zen...
|
| _assassination attempt*
| https://old.reddit.com/r/hardware/comments/849paz/assassinat...
|
| doxxing the researchers:
| https://old.reddit.com/r/hardware/comments/845xks/some_backg...
|
| https://old.reddit.com/r/Amd/comments/84tftt/clarification_a...
|
| https://old.reddit.com/r/Amd/comments/8589t2/cts_labs_clarif...
|
| HN discussions were not much better, although tpacek is cool.
|
| https://news.ycombinator.com/item?id=16576342
|
| https://news.ycombinator.com/item?id=16576516
|
| https://news.ycombinator.com/item?id=16597626
| transpute wrote:
| Android pKVM hypervisor tries to constrain vendor-specific Arm
| EL3 TrustZone (~x86 SMM Ring-2) on Pixel 7/8/9,
| https://lkml.org/lkml/2022/11/16/1241 pKVM's
| primary goal is to protect guest pages from a compromised host by
| enforcing access control restrictions using stage-2 page-tables.
| Sadly, this cannot prevent TrustZone from accessing non-secure
| memory, and a compromised host could, for example, perform a
| 'confused deputy' attack by asking TrustZone to use pages that
| have been donated to protected guests. This would effectively
| allow the host to have TrustZone exfiltrate guest secrets on its
| behalf, hence breaking the isolation that pKVM intends to
| provide.. FF-A provides (among other things) a set of
| memory management APIs allowing the Normal World to share, donate
| or lend pages with Secure. By monitoring these SMCs, pKVM can
| ensure that the pages that are shared, lent or donated to Secure
| by the host kernel are only pages that it owns.. the robustness
| of this approach relies on having all Secure Software on the
| device use the FF-A protocol for memory management transactions
| with the normal world, and not use vendor-specific SMCs that pKVM
| is unable to parse.
|
| On x86, SMM attestation was introduced by Intel (PPAM / Hardware
| Shield, 11+ gen) and AMD, https://www.microsoft.com/en-
| us/security/blog/2020/11/12/sys...
|
| _> Because of its traditionally unfettered access to memory and
| device resources, SMM is a known vector of attack for gaining
| access to the OS and hardware.. One could have perfect code in
| SMM and still be affected by behavior like trampolining into
| secure kernel code.. Isolating SMM is implemented in three parts:
| OEMs implement a policy that states what they require access to;
| the chip vendor enforces this policy on SMIs; and the chip vendor
| reports compliance to this policy to the OS._
___________________________________________________________________
(page generated 2024-09-12 23:00 UTC)