6 ms·

This is entirely defeated by https://trustedcomputinggroup.org/resource/pc-client-work-group-platform-reset-attack-mitigation-specification/ https://trustedcomp

by mjg59 2y ago

This is entirely defeated by https://trustedcomputinggroup.org/resource/pc-client-work-group-platform-reset-attack-mitigation-specification/ 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?

cyberax 2y ago
This still won't prevent yoinking the entire RAM modules and dumping them offline. Ideally, the keys should just remain inside the SRAM cache on the CPU, never even going outside of the CPU die.
- bangaladore 2y ago
  > 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.
  - bri3d 2y ago
    > Theoretically no, but realistically I doubt even intel agencies can pull this off. For older LPDDR3 it's completely practical, see https://www.youtube.com/watch?v=nTvIQDe0rQU https://www.youtube.com/watch?v=nTvIQDe0rQU . It definitely gets harder with newer systems, though. > 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.
    - bangaladore 2y ago
      > 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.
- zebra_bong3 2y ago
  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/ https://forte-research.com/UnTrustZone/ There is no absolute security, but keeping secure memory away from software provides much better solution.
  - mjg59 2y ago
    Just have the CPU microcode clear SRAM whenever the CPU is booted
    - zebra_bong3 2y ago
      That is what that paper says. No cpu does that.
  - cyberax 2y ago
    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.
bri3d 2y ago
Purportedly Windows makes use of this, FWIW: https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/countermeasures https://learn.microsoft.com/en-us/windows/security/operating... "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.
- bangaladore 2y ago
  > "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.
  - mjg59 2y ago
    This is exactly what I was mentioning. Despite being a TCG spec, it's implemented in firmware and has no hard requirement on a TPM at all.
    - bangaladore 2y ago
      Okay, thanks for the correction. The naming there is definitely confusing. Particularly as it sounds like a key attribute bit.
- gruez 2y ago
  >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 https://en.wikipedia.org/wiki/Cold_boot_attack https://en.wikipedia.org/wiki/Cold_boot_attack
arghwhat 2y ago
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.
- 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...

by mjg59 2y ago

cyberax 2y ago

This still won't prevent yoinking the entire RAM modules and dumping them offline. Ideally, the keys should just remain inside the SRAM cache on the CPU, never even going outside of the CPU die.

bangaladore 2y ago
> 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.
- bri3d 2y ago
  > Theoretically no, but realistically I doubt even intel agencies can pull this off. For older LPDDR3 it's completely practical, see https://www.youtube.com/watch?v=nTvIQDe0rQU https://www.youtube.com/watch?v=nTvIQDe0rQU . It definitely gets harder with newer systems, though. > 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.
  - bangaladore 2y ago
    > 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.
zebra_bong3 2y ago
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/ https://forte-research.com/UnTrustZone/ There is no absolute security, but keeping secure memory away from software provides much better solution.
- mjg59 2y ago
  Just have the CPU microcode clear SRAM whenever the CPU is booted
  - zebra_bong3 2y ago
    That is what that paper says. No cpu does that.
- cyberax 2y ago
  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.

bri3d 2y ago

Purportedly Windows makes use of this, FWIW: https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/countermeasures https://learn.microsoft.com/en-us/windows/security/operating... "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.

bangaladore 2y ago
> "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.
- mjg59 2y ago
  This is exactly what I was mentioning. Despite being a TCG spec, it's implemented in firmware and has no hard requirement on a TPM at all.
  - bangaladore 2y ago
    Okay, thanks for the correction. The naming there is definitely confusing. Particularly as it sounds like a key attribute bit.
gruez 2y ago
>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 https://en.wikipedia.org/wiki/Cold_boot_attack https://en.wikipedia.org/wiki/Cold_boot_attack

arghwhat 2y ago

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.

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