Christopher Domas: Hardware Backdoors in X86 CPUs

https://github.com/xoreaxeaxeax/rosenbridge

by summarity • 8 years ago

218 67 8 years ago

github.com

based2• 8 years ago

https://www.reddit.com/r/programming/comments/95zgaq/rosenbr...

olliej• 8 years ago

Seems via specific? Rather than “all x86”

classichasclass2• 8 years ago

It is highly specific, yes. But who knows what else is lurking?

When chips have these undocumented co-processors in them with unlimited privilege to the system, sooner or later they're going to be exploited.

agumonkey2• 8 years ago

Yeah it opens my eyes on the real life implementation of processors, it's not just x86 assembly, a chip is free to have anything in it.

/me sets up his x-ray machine

thinkythought• 8 years ago

This is still a huge target. I used to be in point of sale engineering, and the majority of the quality terminals the big OEMs(NCR and their sub brands, posiflex, etc) were pushing were running these for a LONG time past when you'd think C3 was "dead". Similar vendors i bumped into were pushing stuff with them in it still when i got out of that industry.

There are a LOT of machines out there which will be run essentially until they break down(and a lot are fanless, and will pretty much last until they can't be kept up to date). You have to remember, a lot of big chains(and banks!) paid for extended XP support and then extended-extended XP in the form of windows POS.

This is a "every terminal in a huge fast food chain gets owned and no one finds out for years" sort of vulnerability. This is the first step to something like the target breach all over again.

ryanlol• 8 years ago

This is a "every terminal in a huge fast food chain gets owned and no one finds out for years" sort of vulnerability. This is the first step to something like the target breach all over again.

Utter nonsense, this bug will not lead to RCE.

You might be able to implement a fancy rootkit with this, but that's all. Advanced rootkit tech is neither necessary nor particularly helpful for these sorts of breaches.

pkaye• 8 years ago

VIA processors are renowned for their low power usage and excellence in embedded designs; we believe that the functionality described was created in good faith as a useful feature for the embedded market, and was unintentionally left enabled on some early generations of the processor.

What is the use of this feature?

hakfoo• 8 years ago

I could see using a secondary core as a watchdog in an embedded environment-- if something went too wrong, perhaps the secondary CPU can either get some valuable logging data or stuff the system with code designed to restore it to a controllable state.

CyanLite2• 8 years ago

Title should be renamed to: Hardware Backdoors in Obscure x86 CPUs made in 2003.

dvfjsdhgfv• 8 years ago

Still, the consequences are huge. Also, how can we be sure something similar isn't implemented in modern CPUs?

iodiniemetra• 8 years ago

This is absolutely implemented in modern CPUs, as debug or management features. Usually switched off - being able to turn it on from ring 3 would be a massive bug.

ChuckMcM3• 8 years ago

... and embedded in ATMs with a 20 year life span.

Your comment sounds a bit dismissive of the vulnerability with an implication that it would never be a problem. If that was not what you were implying I apologize. It is critical that even "old" chips vulnerabilities be understood so that one can understand the risks. It pains me terribly every time I power up the Agilent signal analyzer in the lab and it boots Windows XP on its Pentium III chip.

nrdgrl• 8 years ago

I wonder if any of these chips ended up in electronic voting machines?

Dylan168073• 8 years ago

... and embedded in ATMs with a 20 year life span.

Privilege escalation is not a problem on ATMs.

It pains me terribly every time I power up the Agilent signal analyzer in the lab and it boots Windows XP on its Pentium III chip.

Why? Just treat it as you do most hardware, under full control of whatever you attach it to. Zero security present, zero security needed.

tinus_hn• 8 years ago

I don’t think these ATMs run a lot of untrusted code, and this is of course easily patched by clearing the bit during the boot sequence.

It would be much more of a problem if these were consumer machines running untrusted code.

glangdale• 8 years ago

I don't think minimizing the significance of the exploit should happen in the headline, but saying "x86 CPUs" instead of "Via CPUs" in the headline is very clickbaity.

dzdt• 8 years ago

"Via x86 CPUs" would be perfect. It conveys detailed information to those with detailed knowledge while still being understandable to those less familiar with tertiary cpu manufacturers.

DoctorOetker• 8 years ago

Sandsifter was pure genius, I can't wait to read the whitepaper for this one!

agumonkey2• 8 years ago

The talk is worth its weight in gold https://www.youtube.com/watch?v=KrksBdWcZgQ

basementcat2• 8 years ago

This is by the same badass who wrote a compiler that generates only MOV instructons [1]

[1] https://github.com/xoreaxeaxeax/movfuscator

e19293001• 8 years ago

From the FAQ: Q: Why did you make this? A: I thought it would be funny.

phs318u2• 8 years ago

Thanks for that little side-bar/rabbit-hole. Fascinating, as is the paper he based it on. I'm itching to get home and try this out - specifically, I'm interested on what the performance might be like.

stefs• 8 years ago

performance: something that takes seconds now takes hours.

ah, here it is - branchless doom (in the validation/doom directory - https://github.com/xoreaxeaxeax/movfuscator/tree/master/vali... ):

The mov-only DOOM renders approximately one frame every 7 hours, so playing this version requires somewhat increased patience.

mrpippy• 8 years ago

These were designed by Centaur Technology (based in Austin, TX), I'd love to hear from any alums (danluu?) what the purpose of the coprocessor is.

BTW there's an interesting documentary about Centaur, free to watch on Prime Video.

https://www.amazon.com/Rise-Centaur-Glenn-Henry/dp/B01FSZU6F...

exikyut2• 8 years ago

I'd love to hear from any alums (danluu?) what the purpose of the coprocessor is.

Absolutely agree there, I can imagine it being ridiculously interesting.

But the truth might also be equal parts boring and scary instead. I mean...

The backdoor allows ring 3 (userland) code to circumvent processor protections to freely read and write ring 0 (kernel) data. While the backdoor is typically disabled (requiring ring 0 execution to enable it), we have found that it is enabled by default on some systems.
The core executes these commands (which we call the 'deeply embedded instruction set'), bypassing all memory protections and privilege checks.
The rosenbridge backdoor is entirely distinct from other publicly known coprocessors on x86 CPUs, such as the Management Engine or Platform Security Processor; it is more deeply embedded than any known coprocessor, having access to not only all of the CPU's memory, but its register file and execution pipeline as well.

This is enough anti-plausible-deniability that I can just sweepingly point everybody in the direction of the big fat (flashing!) elephant in the room and the "..." sitting next to it.

I mean, VIA didn't have as much success as Intel or AMD, but they are a known name. Anything that implements x86 is going to have market penetration to some extent, and VIA achieved success in the industrial and embedded sectors.

If danluu was able to comment here and debunk what I'm saying, I would be both very surprised and even more delighted.

luu• 8 years ago

If I knew anything non-public (and in this case I don't -- this is from before my time there), I wouldn't be able to talk about it :-)

This has now been pointed out in another thread, but this feature is documented in the datasheet here: http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia.... See Appendix A, A-9 & A-10, as well as the section on CPUID bits.

0x0• 8 years ago

This is a HUGE wake-up call.

It really is incredible to see that a third party apparently has discovered a genuine backdoor in a production CPU with completely independent research. If that's within reach for a standalone researcher, what secrets lie in well-funded organizations at the nation level?

Perhaps this will bring further mindshare to the RISC-V approach in the future?

earenndil• 8 years ago

That would be nice, but I'm more hopeful in the immediate for openpower to gain widespread usage on the desktop. Google seems to be banking on it for servers, at the very least.

analognoise2• 8 years ago

Isn't openpower not actually very open? At least with RISCV we can compete vendors while maintaining a compatible instruction set, I'm not sure how many people are going to produce openpower chips.

wmf4• 8 years ago

Perhaps this will bring further mindshare to the RISC-V approach in the future?

Security people will just move the goalposts to "we assume the actual chip has backdoors that aren't present in public source code".

userbinator2• 8 years ago

Personally I'd love to see a CISC-V --- the world really doesn't need any more MIPS-lookalikes, and a formal spec of x86 would be extremely useful for everyone from emulator writers to maybe even Intel itself.

zaarn• 8 years ago

This affects CPUs made in 2003 by Via, largely. If you use an ATM as your daily driver to browser the internet, this would be a problem.

wmf4• 8 years ago

VIA/Centaur C3 processors are internally RISC and the front end converts x86 instructions into RISC instructions that the processor executes. People used to ask "can I generate native RISC code?" and Centaur always said no, but you know they must have debugging functionality to do that.

And now someone has discovered that sometimes you can enter debug mode from ring 3 and they're calling it a backdoor.

basementcat2• 8 years ago

Waits for Chris Domas to write an LLVM backend for the internal RISC target so we can get 1337 performance out of our C3's.

q3k• 8 years ago

How is it not a backdoor? Just because it's unintended or due to a very complex reason doesn't mean it's not one.

wmf4• 8 years ago

Not every security vulnerability is a backdoor. (The Intel ME isn't a backdoor either.)

drb91• 8 years ago

Well, if it's a documented feature, I'd call it that. You don't call "single user mode" a backdoor.

Granted, you can disable single user mode.

newnewpdro• 8 years ago

Couldn't resist:

https://www.youtube.com/watch?v=ahcVp8vIicI&t=20s

jackhack• 8 years ago

Not a backdoor; more accurately described as "lack of a door".

userbinator2• 8 years ago

This. When I read the article I instantly recognised this from some datasheet-browsing I did many years ago. It's not a "coprocessor", it's not a backdoor, it's just access to the internal core. It's even documented in the datasheet itself:

http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia...

(Page 82, "Alternate Instruction Execution")

Edit: Now it's all coming back to me. I was exploring the 0F opcode space and came upon 0F 3F, which happens to be the "enter alternate execution mode" instruction when it's enabled. There are a lot of other interesting results if you Google "0F 3F", although I remember them being a lot more relevant when I originally discovered this...

https://spth.virii.lu/29a7/Articles/29A-7.029.txt

It's not just the C3 that has this feature, if you Google "ALTINST" you'll find more info.

exikyut2• 8 years ago

Ah, this kind of deflates things a bit, heh. But then concrete knowledge is better than hype, so this is still interesting.

But the fact that you can twiddle kernel memory from userspace is still fun...

I still wonder why entering debug mode got enabled on some models, but not others. 11th-hour release-to-fab glitch? :/

lifthrasiir• 8 years ago

While it is (a bit disappointingly) a known instruction, it seems that Domas has came up with this by his own (via sandsifter [1]). Also, it is really unexpected that there is a documented userland instruction that goes to ring 0 anyway, so it is a "documented" "backdoor". In any case I still think that this study is interesting, mainly because it shows that we can inspect such instructions seemingly out of nowhere.

[1] https://github.com/xoreaxeaxeax/sandsifter

firefenix• 8 years ago

"It's just access to the internal core"

For which the instruction set is not documented. For which the x86 access instruction ("bound eax") is not documented. For which the capabilities are not documented. From which you can circumvent all of the processor's security checks.

This is a _textbook_ definition of a backdoor.

describrion• 8 years ago

This is an irritating comment, I don't understand some people's urge to disparage others' research even at the expense of rationality.

Even modern Intel and AMD processors are "RISC" under the hood - they decompose CISC x86 instructions into RISC micro-ops, this isn't a VIA phenomenon. But they DON'T open up access to their microcode to some arbitrary user letting you circumvent ring protections to access the kernel from ring 3. If they did that would be a - wait for it - backdoor.

admax88q• 8 years ago

They so clearly titled this "X86 CPUs" instead of "VIA C3 CPUs" or "VIA C3 x86 CPUs" on purpose.

Clickbait title in my opinion, they wanted the casual observer to confuse this with Intel/AMD at first glance.

derpherpsson• 8 years ago

This is absolutely insane! With all the recent bugs and features that looks like backdoors I have completely lost faith in x86.

We need simple open ISAs (like RISC-V) and a handfull of trusted organizations that inspect the manufacture processes to protect ourselves from this. A bit like how countries and organizations send people to inspect other countries democratic voting processes, or like how IAEA inspect nuclear stockpiles etc.

I call for:

+ Open source.

+ No creeping featurism.

+ Multiple inspection organizations that watch the process from source code to final chip product.

raxxorrax2• 8 years ago

We should go back to real mode. Imagine all the sudden possibilities. No pesky memory barriers, no protection faults and superb integration of applications of all kind. Application could even share the same memory and the better one wins.

"If nothing is secure, everything is secure" - Lincoln

But seriously: I don't think this "feature" is a real backdoor. It is nonetheless an interesting topic.

I am more concerned about bugs and backdoors in modules like TPM/ME or other even less documented surprises. Wouldn't be the first time that happened and we can only hope, that better people find these type of vulnerability first.

pingiun• 8 years ago

Have you heard of Temple OS? It's an operating system where everything runs in ring 0.

raxxorrax2• 8 years ago

Never heard of it but it seems interesting. Exceptional crazy perhaps but I will definitely take a deeper look.

enyone• 8 years ago

Documented instruction set switch which is just implemented poorly. But the real news here seems to be that the ALTINST is set to 1 by default in some C3 generations.

Christopher Domas: Hardware Backdoors in X86 CPUs

Related Stories