This is entirely defeated by https://trustedcomputinggroup.org/resource/pc-client-work-gr... - if enabled, if the OS isn't cleanly shut down (giving it an opportunity to wipe encryption keys) the firmware will pause to wipe RAM before booting anything else on next boot. Does Windows not make use of this, or did the tested system not implement it?
"BitLocker uses the TCG Reset Attack Mitigation, also known as MOR bit (Memory Overwrite Request), before extracting keys into memory."
I would extremely not trust most platform implementation of TCG Reset Attack Mitigation, though. I've never seen a UEFI platform that is even close to correctly implemented in any form. It would be interesting to know which platform this researcher was working with, and whether it purports to support the MOR bit or not.
>However, this measure can still be circumvented by removing the memory module from the system and reading it back on another system under the attacker's control that does not support these measures
> "BitLocker uses the TCG Reset Attack Mitigation, also known as MOR bit (Memory Overwrite Request), before extracting keys into memory."
(Edit: No this is a UEFI request to clear memory. Below is incorrect.)
I don't think this is what the commenter was mentioning. I think this essentially makes it only possible to extract the key from the TPM once and then the TPM needs to be powered off and back on to get it again.
The TPM has no control over whats in the system memory, so if they key is in system memory, no TPM mitigations are going to help.
UEFI firmware must support clearing the keys from RAM.
That's a very stupid mitigation as you can mess with RAM during the overwrite. Heck, see how Team Tweezers originally exploited the Wii.
The real mitigation is the memory encryption feature of modern CPUs. Being on-die means tweezers won't reach, and being just a key means the wipe is instant and very difficult to mess with even if it survived a power cycle.
After reading the article again, I think this might be an actual interesting Windows vulnerability - rather than a platform issue with MOR, I think this might be bad Windows code where the key is left over in places that aren't protected by MOR. It's quite unclear the more I think about it what's going on here, and the article lacks detail. It's very suspicious to me that the key has disappeared from the `ksecdd` pool but remains in the `dumpfve` pool, and this has my bug spidey-sense tingling.
I'm surprised given that the article mentions stepping into the boot process and `SymCryptSessionDestroy` that they didn't look more deeply into this; it's not how I really intended to spend my new years but I might have a new debugging project now...
Hello! I'm the author of the article and I actually did look into that. I used windbg and stepped through the process of windows booting up to the point of expecting a password. I also looked at what happens when you trigger bitlocker in a way where it requests a recovery key.
I really only did this so I could verify when/whereish the key ends up in memory, so I didn't follow along every single step of the way. I can tell you that SymCrypt succeeds in zeroing out the key multiple times in several places. Thats why I was shocked to find the key left over completely intact in ExAllocatePool allocations, but what I'm guessing is that Microsoft is not accounting for every possible place the key can end up when they're destroying secrets.
Based on previous attacks like this I suspect that Microsoft also employs some "security through obscurity" tactics when they modify BitLocker. What I mean by that is I think there is a lot of just moving the key around so its a little harder to find...
MOR should be wiping everything, especially since after a cold boot the firmware has no idea what the previous memory map was. But I can imagine a universe where it doesn't wipe the boot services heap space (because some of that is obviously in use) and maybe a copy is hanging out there in a predictable way?
It's something that's only triggered in the event of an unclean reboot so under normal circumstances it should be irrelevant and trying to be more elegant potentially increases risk?
The inelegant approach increases risk by relying entirely on the OS being sure that the key is never recoverable from memory on clean shutdown, and on the firmware ensuring that all used RAM is sufficiently wiped in all unclean scenarios.
What if Windows forgot to wipe a spot after having relocated a page? What happens if the firmware's boot flow is interrupted by, say, a hardware fault prompt, a low battery prompt, etc.? There's a lot of places where that approach can go wrong.
The key approach is simpler and comparatively bullet proof: If the machine is rebooted, clean or not, the key will be lost and no memory that was previously used will be readable. All it takes is the OS initializing a single CPU feature on boot, with the only downside being that it requires support for a quite modern CPU feature.
> This still won't prevent yoinking the entire RAM modules and dumping them offline.
Theoretically no, but realistically I doubt even intel agencies can pull this off.
> Ideally, the keys should just remain inside the SRAM cache on the CPU, never even going outside of the CPU die.
The real solution is putting the keys somewhere with a guarantee they will be gone prior to possibly executing untrusted code. In my mind the only real solution is UEFI APIs to support this (or wiping the ram as shown here). But then you have to trust the UEFI vendors which don't exactly have stellar track records.
> In my mind the only real solution is UEFI APIs to support this (or wiping the ram as shown here). But then you have to trust the UEFI vendors which don't exactly have stellar track records.
This already exists: it's the MOR bit and it's supposed to be in play here.
I actually think that having a CPU scratchpad key area which is guaranteed to be wiped across any reset action is a much better idea than trusting any dumpster fire UEFI implementation of anything, ever. At least you're trusting a few CPU vendors with something you can audit that way, rather than a million different cobbled-together junky firmware blobs.
> I actually think that having a CPU scratchpad key area which is guaranteed to be wiped across any reset action is a much better idea than trusting any dumpster fire UEFI implementation of anything, ever. At least you're trusting a few CPU vendors with something you can audit that way, rather than a million different cobbled-together junky firmware blobs.
True. Given that the CPU is what's resetting and running the UEFI code, you better hope it could recognize and clear a scratchpad reliably.
The issue is that any memory readable by a software directly has some kind of risks, including SRAM. Here is something something you might find interesting: https://forte-research.com/UnTrustZone/ There is no absolute security, but keeping secure memory away from software provides much better solution.
TrustZone is not a great solution here, the decryption needs to be fast, and this really means that the key should be directly accessible to the kernel.
Having it only inside the cache SRAM mitigates all the offline attacks. SRAM immediately loses content on power disruption (its state is encoded in the current path, not in a capacitor charge). And it's trivial to completely and unconditionally erase on boot.
