3 ms·

It would entirely prevent the described attack. Related attacks may still be possible, but are also significantly harder than simply booting off USB.

by mjg59 2y ago

bri3d 2y ago
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...
- NoInitRD 2y ago
  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...
  - bri3d 2y ago
    Nice. This might be eligible for a bug bounty for you (if you want to deal with it). I think it’s not by design.
- mjg59 2y ago
  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?
  - NoInitRD 2y ago
    This is my understanding of whats going on.
arghwhat 2y ago
Fair enough, but I'll still hold that wiping all system RAM is a comparatively dumb and slow solution even in this specific scenario. :)
- mjg59 2y ago
  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?
  - arghwhat 2y ago
    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.

It would entirely prevent the described attack. Related attacks may still be possible, but are also significantly harder than simply booting off USB.

by mjg59 2y ago

It would entirely prevent the described attack. Related attacks may still be possible, but are also significantly harder than simply booting off USB.

bri3d 2y ago

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

NoInitRD 2y ago
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...
- bri3d 2y ago
  Nice. This might be eligible for a bug bounty for you (if you want to deal with it). I think it’s not by design.
mjg59 2y ago
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?
- NoInitRD 2y ago
  This is my understanding of whats going on.

arghwhat 2y ago

Fair enough, but I'll still hold that wiping all system RAM is a comparatively dumb and slow solution even in this specific scenario. :)

mjg59 2y ago
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?
- arghwhat 2y ago
  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.