Tuesday, August 14th 2018
VIA C3 Processors Compromised by a Simple Shell Command
VIA processors probably make up an infinitesimal amount of the desktop PC market-share, and its makers market the chip only at pre-built machines such as digital-signage kiosks, information kiosks, ticket vending machines, ATMs, etc (which don't need a lot of processing power). At the Black Hat 2018 conference, security researcher Christopher Domas discovered that getting access to root privileges in Linux on a machine powered by VIA C3 "Nehemiah" processors is laughably easy. Just key in ".byte 0x0f, 0x3f" (without quotes) in any Linux CLI in user mode, and voila! You are now the root user.
Domas calls this his own iddqd (the cheat-code for "God Mode" in "Doom"). This backdoor, probably put in place by the processor's designers themselves, completely collapses the ring-based privilege system of the operating system, and elevates users and applications from the ring-2 (and above) userspace to ring 0 (root). It is an exploitation of a shadow-core, a hidden RISC processor within C7, which manages the startup, operation, and key storage of the x86 cores. Intel and AMD too have shadow-cores with similar functions.
Source:
Tom's Hardware
Domas calls this his own iddqd (the cheat-code for "God Mode" in "Doom"). This backdoor, probably put in place by the processor's designers themselves, completely collapses the ring-based privilege system of the operating system, and elevates users and applications from the ring-2 (and above) userspace to ring 0 (root). It is an exploitation of a shadow-core, a hidden RISC processor within C7, which manages the startup, operation, and key storage of the x86 cores. Intel and AMD too have shadow-cores with similar functions.
12 Comments on VIA C3 Processors Compromised by a Simple Shell Command
Most probably run on XP embedded.
1-It was a feature designed for better testing/debugging of engineering samples (for whatever reason), and they forgot to remove it in the final product.
2-Make jumping from any ring to ring 0 much faster (supposedly, jumping from any ring to another is rather expensive), but forgot to add security measures, or the feature got scraped, and again, forgot to actually remove it.
3-It's an actual backdoor, built specifically for that purpose.
2 intentional, never were going to remove or secure it.
3 Government request likely.
Iirc, the chip was supposed to be the next best thing for IoT, until ARM and SoC.
Adding debugging features is very common, and is probably done in every single microchip. But this type of debugging is usually disabled or removed right before mass production, and it's easy to forget something in the final push before a due date.
Still, sometimes they leave stuff there because it's "useful"…
The exploit requires three steps:
1) Writing a CPU configuration register with the wrmsr instruction (MSR 1107, bit 0 - Set to 1). This enables the 0x0f3f instruction. This is only possible from within Ring 0 - Except on a certain subset of C3 CPUs which have this bit enabled by default (C3 Samuel 2 - 0x0C5B), which makes the 0x0f3f instruction always available. A trivial mitigation for the latter case is to have the Kernel write this MSR bit to zero as it loads once it knows that it runs on a CPU of the affected family. With this bit disabled, the exploit is not possible. It can likely also be fixed via BIOS or uCode updates, but who is going to bother for a platform or CPU that old.
2) Using the embedded RISC code to execute a series of instructions that would manipulate Linux Kernel memory to escalate your privilege to become root. These instructions will bypass kernel memory protections because they are not active when the RISC core is executing.
3) Launch a shell (which will open as root) to complete the privilege escalation.
This isn't even remotely close to ".byte 0x0f, 0x3f" in the CLI, which will do nothing.
This is the actual payload used for the exploit (source is his DefCon26 presentation):
Probably? Who else manipulates the RTL for an x86 processor if not the designers themselves. Heck, even if it was a malicious backdoor installed by the request of a government (spoiler: It most likely isn't, so the tinfoil hats can go back into storage), it was still put in place by the designers themselves. Judging by the fact that it was enabled by default only on a subset of the CPUs, this is likely an unfinished feature, or a debug functionality, that was left enabled by default as a result of a mistake. Such unsecured debug feature bugs are extremely common in HW.Anyway, this core is not the SMM, or any manageability-related core which is what Intel and AMD have been repeatedly lampooned about. It is different, and its functionality is not well understood. It is a core that shares the CPU's execution resources (such as registers), which makes it very special indeed, and what enabled Domas to craft his attack. The one hallway speculation I heard was that this core was intended to be used (ironically) for cryptographic offloads, thus to be used to provide security related features.
EDIT: You can read documentation about this feature in the C3 Datasheet on page 80. Here it is.
Not to mention that this article explains nothing of the process Mr. Domas had to go through to discover this (such as reading through patents, narrowing down to the exact bit that would enable the instruction, reverse-engineering the RISC instruction set of the RISC core, writing an assembler for the RISC core and finally crafting the payload), which is the truly interesting part of the story, and what showcases his genius.
You can see his presentation on the DefCon26 media server (Edit: Fixed link). This is pretty much the same one as presented at Blackhat.