X86 rootkit | Hacker News Reader

X86 rootkit

github.com

256 pointsjsprogrammer47 comments

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.

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

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

semi legit, cantor.dust is still vaporware

Yes, true. No beta invite yet.

senseye seems to match the featureset from cantor dust pretty well but other than 'pretty pictures' its hard to see how its useful

The "intuitive" feeling that he claims to develop after using it for awhile seems like it would be useful of you do a lot of reverse engineering or forensics work.

yeah perhaps I just havn't gotten the feel for it - think I've spent some 8-10 hours total playing around (more comfortable with regular hex+disasm+debug+scripts), I liked the https://github.com/letoram/senseye/wiki/Sense_MFile thing though

This looks pretty cool. cantor.dust seemed more usable than senseye (I haven't used either).

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?

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.

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.

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.

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

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

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.

Did I misread? I thought it only requires userland?

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

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

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?

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.

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

Scary.

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

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.

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.

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

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?

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

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

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

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

I believe the author previously disclosed to Intel.

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.

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

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

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.

They had on-package memory controllers. They were on the chip, but were a separate die inside the package.

What does this imply?

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

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

Does this apply to all server boards or only some?

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

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

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.

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.

ring (-2) not ring (2)

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

Reply on news.ycombinator.com