
Christopher Domas: Hardware Backdoors in X86 CPUs - minxomat
https://github.com/xoreaxeaxeax/rosenbridge
======
wmf
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.

~~~
q3k
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.

~~~
drb91
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.

~~~
phs318u
According to the datasheet, this is by design:

"The mechanism for initiating execution of this alternate set of instructions
is as follows: 1\. Set the FCR ALTINST bit to 1 using WRMSR instruction (this
is a privileged instruction). This should be done using a read-modify-write
sequence to preserve the values of other FCR bits. 2\. The ALTINST bit enables
execution of a new x86 jump instruction that starts execution of alternate
instructions. This new jump instruction can be executed from any privilege
level at any time that ALTINST is 1."

So to turn on the ability to execute ring-0 non-x86 instructions from ring 3,
requires an initial privileged instruction. I believe (from other commenters)
that the issue arises because some of the cpu's left the fab with ALTINST set
to 1 by default. Meaning, no privileged instruction required. Clearly, that's
a fuck-up somewhere.

------
admax88q
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.

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

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

~~~
phs318u
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
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...](https://github.com/xoreaxeaxeax/movfuscator/tree/master/validation/doom)
):

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

------
mrpippy
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...](https://www.amazon.com/Rise-Centaur-Glenn-
Henry/dp/B01FSZU6FK)

~~~
exikyut
> _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
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...](http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemiah%20Datasheet%20R113.pdf).
See Appendix A, A-9 & A-10, as well as the section on CPUID bits.

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

~~~
ChuckMcM
... 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
I wonder if any of these chips ended up in electronic voting machines?

~~~
jacobush
That is one place you don't need hacking CPUs to hack the result. Plain files
vetted by no one etc etc.

------
pkaye
> 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
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.

------
raxxorrax
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
Have you heard of Temple OS? It's an operating system where everything runs in
ring 0.

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

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

~~~
agumonkey
The talk is worth its weight in gold
[https://www.youtube.com/watch?v=KrksBdWcZgQ](https://www.youtube.com/watch?v=KrksBdWcZgQ)

------
olliej
Seems via specific? Rather than “all x86”

~~~
thinkythought
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
>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.

------
enyone
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.

------
based2
[https://www.reddit.com/r/programming/comments/95zgaq/rosenbr...](https://www.reddit.com/r/programming/comments/95zgaq/rosenbridge_hardware_backdoors_in_x86_cpus_repo/)

------
0x0
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
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.

~~~
analognoise
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.

~~~
classichasclass
In the long term, I think you have a point here. It would be nice to have IBM
not being the only producer of, say, the POWER15. In that sense RISC-V is
substantially more open than OpenPOWER.

But parent was talking about in the immediate timeframe, and right now (and I
predict for the next few years at minimum), if you want free(r) and ballpark
performance class with x86, then you're going to have to play with POWER. I
don't think ARM is there yet with respect to grunt and some ARM designs have
some of the same concerns about creepy dark corners of the processor die. It's
why there's a Talos II under my desk.

~~~
analognoise
I wanted one of those, just couldn't justify the price. I've been toying with
the idea of running Reactos or Haiku on an FPGA as a cheaper "you own it as
much as possible" variant.

------
derpherpsson
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.

