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