X86 rootkit

https://github.com/xoreaxeaxeax/sinkhole

by jsprogrammer • 11 years ago

256 47 11 years ago

vardump2• 11 years ago

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.

jsprogrammer7• 11 years ago

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

TazeTSchnitzel2• 11 years ago

The "magic number" is just a signal to the rootkit. It's not a rootkit itself.

rasz_pl2• 11 years ago

semi legit, cantor.dust is still vaporware

userbinator• 11 years ago

The severity of this depends on whether you consider SMM the same privilege level as ring 0, or higher. From my understanding, SMM seems like it was never really designed to be a higher privilege level with strong isolation guarantees.

bonzini• 11 years ago

It was not designed as one, but it was mutated into one. SMRR were added for that reason, and various fixes were made to the chipsets in order to isolate SMM better.

Remember that SMM is _the_ trusted base for UEFI secure boot.

mjn• 11 years ago

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

jsprogrammer7• 11 years ago

2-page description from the author: https://www.blackhat.com/docs/us-15/materials/us-15-Domas-Th...

Rantenki• 11 years ago

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... ), but remediation after exploit via total hardware replacement would _suck_ for anybody with servers just a couple of years old.

strstr3• 11 years ago

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

cft• 11 years ago

Does this apply to all server boards or only some?

jwatte• 11 years ago

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

x02• 11 years ago

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

Scary.

reirob• 11 years ago

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

x02• 11 years ago

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.

im3w1l• 11 years ago

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

jsprogrammer7• 11 years ago

I believe the author previously disclosed to Intel.

Sanddancer3• 11 years ago

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• 11 years ago

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

wtallis• 11 years ago

Sandy Bridge was the first Intel chip to have on-die memory controller and on-die GPU, but most of its predecessors from the Nehalem/Westmere microarchitecture had on-die memory controllers.

MrBra• 11 years ago

What does this imply?

mappu2• 11 years ago

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?

strstr3• 11 years ago

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

strstr3• 11 years ago

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• 11 years ago

Did I misread? I thought it only requires userland?

TazeTSchnitzel2• 11 years ago

You didn't read past the first page. The only userland thing is activating the rootkit.

3JPLW• 11 years ago

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

flashman• 11 years ago

Previous discussion: https://news.ycombinator.com/item?id=9663249

vardump2• 11 years ago

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

hmottestad• 11 years ago

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

pmalynin• 11 years ago

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.

mappu2• 11 years ago

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.

recentdarkness• 11 years ago

ring (-2) not ring (2)

rootlocus• 11 years ago

Read us-15-Domas-TheMemorySinkhole.pdf for an in depth explanation.

thomasrossi• 11 years ago

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• 11 years ago

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.

anonbanker• 11 years ago

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

zachberger• 11 years ago

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

X86 rootkit

Related Stories