
X86 rootkit - jsprogrammer
https://github.com/xoreaxeaxeax/sinkhole
======
vardump
Read through it all. Seems legit so far. This is _bad_.

Exploiting non-vulnerable SMM code through a remap flaw in x86 architecture.
Ouch.

Not only can this arbitrarily exploit the running OS. It might actually be
able to physically destroy the computer it's running on, for example by
abusing thermal controls.

Doesn't affect Sandy bridge or newer.

~~~
jsprogrammer
Yep. I didn't read most of the last 1/2-1/3 of the slides, but it looks like
the magic number may be different for each machine (ie. there is no one binary
to rule them all[all though you could probably trivially generate all
possibilities])? And that there is at least some process involved in
determining the number what the number is?

The author is legit. Here's a somewhat recent talk he gave:
[https://www.youtube.com/watch?v=C8--
cXwuuFQ](https://www.youtube.com/watch?v=C8--cXwuuFQ)

~~~
rasz_pl
semi legit, cantor.dust is still vaporware

~~~
jsprogrammer
Yes, true. No beta invite yet.

~~~
rasz_pl
invites to what? CIA front for reverse engineering? Guy works for a non profit
that happens to be the biggest employee for RE coders, nobody heard of it
_and_ its only client is DoD, all of this is dodgy as F

edit: quick google shows Battelle Memorial is a 'known' CIA front company.

/tinfoilhat mode

Now Im starting to suspect this SMM escalation was in their arsenal and he
overheard some details in the cafeteria?

~~~
jsprogrammer
Invite to candor.dust?

What is the relevance of a CIA front? The software was demo'd, explained, and
makes sense.

More likely, the software is quite powerful and was developed into a larger,
more automated version that Domas/Battelle/CIA/whoever doesn't want to give
away.

------
mjn
Looks like this was a talk at the Black Hat conference today. In addition to
the slides PDF in the Github repository, the Black Hat site also has a short
paper: [https://www.blackhat.com/us-15/briefings.html#the-memory-
sin...](https://www.blackhat.com/us-15/briefings.html#the-memory-sinkhole-
unleashing-an-x86-design-flaw-allowing-universal-privilege-escalation)

------
jsprogrammer
2-page description from the author:
[https://www.blackhat.com/docs/us-15/materials/us-15-Domas-
Th...](https://www.blackhat.com/docs/us-15/materials/us-15-Domas-The-Memory-
Sinkhole-Unleashing-An-x86-Design-Flaw-Allowing-Universal-Privilege-
Escalation-wp.pdf)

------
strstr
The APIC's registers are an unusual form of per core black magic. As far as I
know, no other memory addresses behave in the same way -- visible and reacting
only to that specific core. It's unsurprising that Intel initially didn't
catch this case.

Fortunately, it's `just` a root => SMM escalation, which are already more
common than anyone would really like to admit.

~~~
eximius
Did I misread? I thought it only requires userland?

~~~
3JPLW
The presentation certainly makes it seem that way. The dramatic "POC" with the
magic number only works with the rootkit already installed.

The proceedings paper has much more detail[1]. Installing the rootkit requires
some very careful crafting and requires ring 0 to request memory remapping and
set up far pointer descriptors.

1\. (pdf) [https://www.blackhat.com/docs/us-15/materials/us-15-Domas-
Th...](https://www.blackhat.com/docs/us-15/materials/us-15-Domas-The-Memory-
Sinkhole-Unleashing-An-x86-Design-Flaw-Allowing-Universal-Privilege-
Escalation-wp.pdf)

------
thomasrossi
Hm, what is really interesting would be to understand how this can impact a
shared machine, say an EC2. Is there any more reasearch on this?

~~~
cnvogel
The hypervisor on EC2 will (or rather: it can, and I assume it will) block
your virtualized Kernel (running on Ring-0) from messing with the APIC. This
(running a hypervisor) is one of the possible mitigations for the sinkhole-
exploit.

------
x0
Oh man... when I read the title, I was thinking "sure, x86, whatever, but what
_OS_ is this rootkit for?"

Scary.

~~~
reirob
By reading the 2 page paper from the author [0] - it's linked to somewhere in
this thread:

"[...] SMM code is installed during the boot process by system firmware, the
diversity of which typically precludes a widespread attack. However select
components of system firmware are derived from a set of Unified Extensible
Firmware Interface (UEFI) template code provided by Intel. Such is the case
for the initial SMM entry point, which is almost universally deployed on
modern systems. An attack directed against this specific code sequence
achieves the widest possible coverage. [...]"

So theoretically it's exploitable on all Operating Systems. The exploit is
using the combination of a hardware bug and UEFI code.

The hardware bug consists in allowing to relocate the APIC (Advanced
Programmable Interrupt Controller) memory range to the memory range used by
the SMM (System Management Mode) and so influencing the data in some of SMMs
memory.

[0] [https://www.blackhat.com/docs/us-15/materials/us-15-Domas-
Th...](https://www.blackhat.com/docs/us-15/materials/us-15-Domas-The-Memory-
Sinkhole-Unleashing-An-x86-Design-Flaw-Allowing-Universal-Privilege-
Escalation-wp.pdf)

~~~
x0
Oh, I was aware, but that was just my immediate thought, because I'd never
really conceived of something like it. Thanks, though! I'm sure someone
reading this thread found your comment very helpful.

------
Rantenki
It's going to be interesting to see what the ramifications are this for
trusted execution environments, where people are validating the hardware they
are running on via tboot.

It's fortunate that newer platforms seem to be immune (see [https://security-
center.intel.com/advisory.aspx?intelid=INTE...](https://security-
center.intel.com/advisory.aspx?intelid=INTEL-SA-00045&languageid=en-fr) ), but
remediation after exploit via total hardware replacement would _suck_ for
anybody with servers just a couple of years old.

~~~
strstr
TXT's interactions with SMM are pretty broken [1]. For example, TXT doesn't
(can't) validate SMRAM.

This exploit still requires ring 0, which, hopefully, the code running in TXT
doesn't give access too willy nilly.

[1]
[http://invisiblethingslab.com/resources/bh09dc/Attacking%20I...](http://invisiblethingslab.com/resources/bh09dc/Attacking%20Intel%20TXT%20-%20paper.pdf)

------
mappu
The PDF indicates this requires ring 0 to work, right? So you can't go from
user to root.

However it does mention ring -2 is under the hypervisor, so.. that allows
guest->host escape under VT-x?

~~~
strstr
The whole "ring-2" thing is misleading. Root to SMM doesn't imply a VM escape.

Most hypervisors don't even implement APIC relocation properly (I believe KVM
fixes it to 0xfee00000).

Even if APIC were relocatable in a guest, Host SMM runs outside of the
hypervisor, and wouldn't be influenced by the guest (the guest's APIC MMIO
accesses are all virtualized: either converted into VMEXITs on sandybridge and
earlier, or potentially passed through to the APIC access page.)

------
flashman
Previous discussion:
[https://news.ycombinator.com/item?id=9663249](https://news.ycombinator.com/item?id=9663249)

~~~
vardump
More like previous guessing and hypothesizing. The details weren't known at
that time.

------
im3w1l
Is it a coincidence that newer CPU's aren't vulnerable, or was it fixed
because of discussions with Intel?

~~~
Sanddancer
It's coincidence. The change that causes a GPF when the APIC space overlaps
with SMM space was an undocumented change when Sandy Bridge was rolled out. So
some engineers at Intel may have had an inkling that something could happen
there, but at the same time, Sandy Bridge was the first chip with an on-die
memory controller, so the engineer assigned to the new implementation could
have just been more diligent in thinking through failure scenarios.

~~~
omgmypztxqma
Are AMD's (or other non-Intel shops') CPUs vulnerable to this remap gimmick as
well - or, is it specific to Intel's circuitry? (Sorry, I can't read the
slides at present.)

~~~
Sanddancer
From the slides, it looks like AMD chips are vulnerable as well. They didn't
mention any other X86 vendors.

------
MrBra
What does this imply?

------
anonbanker
Does this affect AMD processors as well? if so, this would be a huge step
toward rooting a PS4/XboxOne.

~~~
zachberger
The slides state they're investigating if its exploitable on AMD

------
cft
Does this apply to all server boards or only some?

~~~
jwatte
Likely most server boards before 2011, and some server boards before
approximately 2013.

------
hmottestad
Should we call it "halt and catch fire 2015"?

------
pmalynin
Eh, ring-2 is pretty lame. Most code either runs in ring-3 or ring-0. I'm not
even sure how one would even get to ring-2.

~~~
mappu
Ring negative-2, not ring 2. It represents SMM (-2) under the hypervisor (-1)
under root (0).

Although OS/2 and eComstation use ring 2 a lot which made them hard to emulate
for a while.

