4 ms·

Can someone translate this to something I can understand?

SlyShy 17y ago
I only skimmed the full report, but it looks like a way of root-kitting a new Intel processor. As noted, Intel has already patched this problem.
- tptacek 17y ago
  Nope, it's a way of installing a persistent rootkit with full access to the hardware (ie, a rootkit like any modern rootkit on non-TXT Intel hardware) even on systems that use TXT and VT-* to prevent that from happening. It's circumvention of a new Intel security feature, but it's not a new compromise in the integrity of the CPU or chipset itself. Even if they hadn't corrected the problem, you'd still be better off with TXT than without it.
deleted 17y ago
[deleted]
tptacek 17y ago
Sure. TXT is Intel's chipset security system. Its best known application is to allow you to boot through a series of cryptographically signed steps, all of which are verified by a hardware module in the chipset. That is, among other things, a defense against rootkits. Modern X86 chips also support hardware virtualization (these are the VT-* technologies). With TXT, you can securely boot into a hypervisor, which is locked into memory and can't be compromised by a generic OS running on the machine even from ring 0, even though the hypervisor is running in the same physical memory as the generic OS. This process only works if neither generic kernel code nor unverified code running at boot can directly access physical memory, so VT-* makes sure to lock down DMA so that peripherals and chipset devices can't do that. But DMA has gotten really complicated. For instance, AGP graphics had a special DMA feature called the GART, which remaps memory to AGP's convenience. There are a bunch more of these DMA remapping features now, and they all need to be accounted for, or else you can reconfigure memory out from under the hypervisor. That's what this paper is about. The TXT/VT-* boot process attempts to account for all the DMA remapping devices. Trusted TXT code checks the PCI configuration to see what remapping features exist. There's a 64/32bit bug in that trusted code, which allows you to screw up a PCI configuration register and get TXT to miss one of the remapping devices. That gives you DMA access later on, and allows you to write directly to memory owned by a hypervisor.
NateLawson 17y ago
In more detail, TXT has an instruction called SENTER. It loads a signed chunk of code into the cache and locks out all RAM accesses. It verifies a signature on the code and if it is valid, jumps to it. Behind the scenes, it also resets the TPM's hash registers (PCRs) to their initial state. Only Intel can supply an AC (authenticated code) module since only they have the signing key. The AC module is typically stored in the BIOS, so this bug would be fixed by a BIOS update. The default AC module just initializes the system to a state where no other code can affect it, hashes the next level bootloader into a PCR, and jumps to it. Since no one can reset PCRs without running SENTER, programs can use the contents of the PCRs to see what code is running. The biggest issue with this advisory is that there is no way to revoke old AC modules that I know of. So an attacker could always run SENTER with the old AC, compromise it, then boot the real hypervisor. When that hypervisor tries to access the PCRs, the rootkit can virtualize them. No one later in the chain can tell the difference. This is a fundamental problem with trusted boot in general -- any time a flaw is found in one link in the chain, everyone after it is compromised.

I only skimmed the full report, but it looks like a way of root-kitting a new Intel processor. As noted, Intel has already patched this problem.

tptacek 17y ago
Nope, it's a way of installing a persistent rootkit with full access to the hardware (ie, a rootkit like any modern rootkit on non-TXT Intel hardware) even on systems that use TXT and VT-* to prevent that from happening. It's circumvention of a new Intel security feature, but it's not a new compromise in the integrity of the CPU or chipset itself. Even if they hadn't corrected the problem, you'd still be better off with TXT than without it.

deleted 17y ago

[deleted]

tptacek 17y ago

Sure. TXT is Intel's chipset security system. Its best known application is to allow you to boot through a series of cryptographically signed steps, all of which are verified by a hardware module in the chipset. That is, among other things, a defense against rootkits. Modern X86 chips also support hardware virtualization (these are the VT-* technologies). With TXT, you can securely boot into a hypervisor, which is locked into memory and can't be compromised by a generic OS running on the machine even from ring 0, even though the hypervisor is running in the same physical memory as the generic OS. This process only works if neither generic kernel code nor unverified code running at boot can directly access physical memory, so VT-* makes sure to lock down DMA so that peripherals and chipset devices can't do that. But DMA has gotten really complicated. For instance, AGP graphics had a special DMA feature called the GART, which remaps memory to AGP's convenience. There are a bunch more of these DMA remapping features now, and they all need to be accounted for, or else you can reconfigure memory out from under the hypervisor. That's what this paper is about. The TXT/VT-* boot process attempts to account for all the DMA remapping devices. Trusted TXT code checks the PCI configuration to see what remapping features exist. There's a 64/32bit bug in that trusted code, which allows you to screw up a PCI configuration register and get TXT to miss one of the remapping devices. That gives you DMA access later on, and allows you to write directly to memory owned by a hypervisor.

NateLawson 17y ago

In more detail, TXT has an instruction called SENTER. It loads a signed chunk of code into the cache and locks out all RAM accesses. It verifies a signature on the code and if it is valid, jumps to it. Behind the scenes, it also resets the TPM's hash registers (PCRs) to their initial state. Only Intel can supply an AC (authenticated code) module since only they have the signing key. The AC module is typically stored in the BIOS, so this bug would be fixed by a BIOS update. The default AC module just initializes the system to a state where no other code can affect it, hashes the next level bootloader into a PCR, and jumps to it. Since no one can reset PCRs without running SENTER, programs can use the contents of the PCRs to see what code is running. The biggest issue with this advisory is that there is no way to revoke old AC modules that I know of. So an attacker could always run SENTER with the old AC, compromise it, then boot the real hypervisor. When that hypervisor tries to access the PCRs, the rootkit can virtualize them. No one later in the chain can tell the difference. This is a fundamental problem with trusted boot in general -- any time a flaw is found in one link in the chain, everyone after it is compromised.