3 ms·

What was the hardware on which this was running? I thought DDR5 would be more resistant to this type of RAM attack.

Arnavion 2y ago
This is not "attacking" RAM. A UEFI binary (or Linux kernel in the CCC demo which uses a different method to retain the key in memory) already has access to all the extents of physical memory. It just has to search it for the scribble leftover from the bootloader. See https://github.com/NoInitRD/Memory-Dump-UEFI/blob/db4888dc056f9d9e10d34ca3541a55e325a8211d/app/Application.c#L119-L131 https://github.com/NoInitRD/Memory-Dump-UEFI/blob/db4888dc05... and onwards. Edit: Ah, I guess you're referring to the fact that the reboot preserves RAM contents? DDR5 doesn't change anything about that AFAIK.
- dogma1138 2y ago
  Indeed, however it should be noted that this is only a single attempt attack and which will trigger the tamper protection. Changing the boot order, making changes to the BIOS or booting from an unsigned bootloader would trigger a bitlocker lockout. This means that if you don’t get the keys on the first attempt you can’t just pass the machine back to the user and try again later since the next time it will boot it would boot into bitlocker recovery. And even if the attack is successful the user will still be aware that something did happen so you are still better off with other physical attacks if they are still possible.
  - mjg59 2y ago
    Why? You're not booting Windows again, and restoring the secure boot state and boot order to the original values will result in the PCR values being what they were before, so what's changing that would force recovery mode?
    - dogma1138 2y ago
      The TPM tracks the state of the secure boot and the bios, that log is stored in the TPM itself the next time you’ll try to boot into windows it will see that something happened and bitlocker will lock itself out. Do this experiment. Boot into any Linux live CD on a machine with bitlocker enabled. Reboot and see what happens.
      - mjg59 2y ago
        No, the TPM doesn't retain PCR measurements over reboots, and the log (rather than the composite PCR value) is handled by the firmware and the OS and the TPM has no idea it exists.
        aspenmayer 2y ago
        It seems that this is a property of TPM 1.2. > On devices with TPM 1.2, changing the BIOS or firmware boot device order https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/recovery-overview https://learn.microsoft.com/en-us/windows/security/operating...
      - vel0city 2y ago
        I did that last night. It didn't have any issues booting back into Windows after booting to a live USB. I didn't change any parameters of the Windows boot option or the rest of the system.
        aspenmayer 2y ago
        It seems that this is a property of TPM 1.2. > On devices with TPM 1.2, changing the BIOS or firmware boot device order https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/recovery-overview https://learn.microsoft.com/en-us/windows/security/operating...
        vel0city 2y ago
        Yeah I seem to recall every time I've done that it seems to auto boot fine when I change it back to what it was before. And as mentioned it's never had issues if I did a one off choice from the boot menu.
    - MoreMoore 2y ago
      It doesn't matter if you change the settings back. I don't know how it works, but something non-user configurable is changed that prompts Windows to require a reset of the TPM keys.

This is not "attacking" RAM. A UEFI binary (or Linux kernel in the CCC demo which uses a different method to retain the key in memory) already has access to all the extents of physical memory. It just has to search it for the scribble leftover from the bootloader. See https://github.com/NoInitRD/Memory-Dump-UEFI/blob/db4888dc056f9d9e10d34ca3541a55e325a8211d/app/Application.c#L119-L131 https://github.com/NoInitRD/Memory-Dump-UEFI/blob/db4888dc05... and onwards. Edit: Ah, I guess you're referring to the fact that the reboot preserves RAM contents? DDR5 doesn't change anything about that AFAIK.

dogma1138 2y ago
Indeed, however it should be noted that this is only a single attempt attack and which will trigger the tamper protection. Changing the boot order, making changes to the BIOS or booting from an unsigned bootloader would trigger a bitlocker lockout. This means that if you don’t get the keys on the first attempt you can’t just pass the machine back to the user and try again later since the next time it will boot it would boot into bitlocker recovery. And even if the attack is successful the user will still be aware that something did happen so you are still better off with other physical attacks if they are still possible.
- mjg59 2y ago
  Why? You're not booting Windows again, and restoring the secure boot state and boot order to the original values will result in the PCR values being what they were before, so what's changing that would force recovery mode?
  - dogma1138 2y ago
    The TPM tracks the state of the secure boot and the bios, that log is stored in the TPM itself the next time you’ll try to boot into windows it will see that something happened and bitlocker will lock itself out. Do this experiment. Boot into any Linux live CD on a machine with bitlocker enabled. Reboot and see what happens.
    - mjg59 2y ago
      No, the TPM doesn't retain PCR measurements over reboots, and the log (rather than the composite PCR value) is handled by the firmware and the OS and the TPM has no idea it exists.
      - aspenmayer 2y ago
        It seems that this is a property of TPM 1.2. > On devices with TPM 1.2, changing the BIOS or firmware boot device order https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/recovery-overview https://learn.microsoft.com/en-us/windows/security/operating...
    - vel0city 2y ago
      I did that last night. It didn't have any issues booting back into Windows after booting to a live USB. I didn't change any parameters of the Windows boot option or the rest of the system.
      - aspenmayer 2y ago
        It seems that this is a property of TPM 1.2. > On devices with TPM 1.2, changing the BIOS or firmware boot device order https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/recovery-overview https://learn.microsoft.com/en-us/windows/security/operating...
        vel0city 2y ago
        Yeah I seem to recall every time I've done that it seems to auto boot fine when I change it back to what it was before. And as mentioned it's never had issues if I did a one off choice from the boot menu.
  - MoreMoore 2y ago
    It doesn't matter if you change the settings back. I don't know how it works, but something non-user configurable is changed that prompts Windows to require a reset of the TPM keys.