Why/When does patching CVE-2022-41099 (BitLocker Bypass) require extra steps?

Question

Microsoft has published information about a recent security problem classified as "BitLocker Security Feature Bypass" identified as CVE-2022-41099 which points out that Windows Recovery Environment (WinRE) images are at this time not automatically updated, but instead require manual steps to actually apply.

Installing the update normally into Windows will not address this security issue in WinRE. [..] You must apply the applicable Windows security update to your Windows Recovery Environment (WinRE).

That sounds like something only justified by exceptional circumstances, given how easily the provided instructions could results in breaking the feature altogether, and how deviating from the usual update methods will delay the updates application on many if not most systems.

A successful attacker could bypass the BitLocker Device Encryption feature on the system storage device.

"Bypass" sounds serious, but at the same time impossible given that the same disk, encrypted the same way is on disk simply either protected or not protected, never conditional on the update status of the system Microsoft has setup to maintain it. Because if it did depend on that, the described "attacker with physical access" could just downgrade the software to get rid of that pesky security update, right?

What is going on here, how can this apparent contradiction be explained and what could qualify a BitLocker-enabled Windows system to justify the extra steps to update the its (never before serviced?) WinRE system.

Answer 1

I am following this discussion with interest but besides the question about how to patch WinRE i have some more thoughts. I learnd from the different variants of patching that it is quite simple to replace the WinRE .wim file with a different version. It is no problem to extract this from windows ISO in an unpatched state. So why should patching solve the problem if i can use any version i want instead? I think this will lead to the result that the patching is useless. Even removing the WinRE from the device is an unclear solution - why not shrinking the partition and creating a new WinRE to start from. Not very complicated? Also - as i can not find any detail about the attack itself - could i move the HDD to a different computer? One mentioned that we might be able to protect the computer with boot password and disable external devices. O.K. this might help allthough the users will not be very happy. But this is only a solution if the attack is needing info from the computer itself like TPM data. At the end i come to the conclusion that patching is not even worth a try as it is simple to be undone by the attacker. Keep in mind - full physical access to the device. At the current state - without any information about the attack itself - i do not see any solution. If i am right with my thoughts this is dramatic problem for "confidentially" of data (MS itself declared the impact as high!). Every windows 10 and 11 device is at high risk and so is localy stored data. Does anyone have information to the attack and how it is done? Well - some may say we should not exploit this here, but do you really think that the attackers are not aware of this info right now?

Answer 2

I only have guesses, but with that said:

1. It might only apply to TPM-only Bitlocker. In TPM-only mode, the encryption key is available to any OS that follows the usual boot process up to a certain point. On Windows, that point is by default reaching the Windows bootloader (this is partially configurable, albeit awkwardly, by modifying the PCRs that Bitlocker checks). Since the copy of WinRE installed on the disk is also accessed through the Windows bootloader, this might mean that the relevant PCRs are the same when booting to WinRE, in which case the Bitlocker key is unsealed. Bitlocker in TPM-only mode relies on the OS user authentication to protect against online attacks, but in WinRE there might be ways to bypass the user authentication since, historically, recovery environments assume that anybody physically at the machine is authorized to service it.
2. The bug might be a missing mitigation against an attacker extracting the key from RAM after booting but before (and without) authenticating to the OS. Normally, when the user isn't logged in (or if the session is locked), Windows disables all DMA (Direct Memory Access) that could access the relevant region of memory, where the Bitlocker key is stored (in some cases it might just block DMA from accessing certain ranges, rather than disabling it entirely). If WinRE allows some form of DMA to read the bitlocker key, then this would put the key at risk. That's especially true in TPM-only mode, but even if there's a boot-time password or external key file, an attacker who finds a booted (but locked) machine would be able to extract the key from it so long as they could do so before the machine shut down.
3. Bitlocker includes the ability to "suspend" encryption at various times, which it does by writing to the volume metadata (in plain text) a value that can be used to decrypt the encryption key. The user can manually suspend BitLocker, but it can also happen automatically during updates that would otherwise prevent the TPM from unsealing the key (in particular, updates to the firmware or bootloader, or possibly in some cases the kernel). Possibly this "suspended" key protector was being written somewhere it shouldn't be, or derived in an unsafe way, or not erased properly when protection was un-suspended. Even through the Bitlocker protectors are written to the volume metadata (not the same as the boot volume), WinRE might sometimes be responsible for them and may have mis-handled them, leading to a vector by which a knowledgeable attacker could extract the volume encryption key as though Bitlocker was suspended even though it wasn't.

There seems to be almost no reliable information about that CVE, so it could also be something else entirely or even some combination of things.

Answer 3

These are not exceptional circumstances.

WinRE is an emergency / "Safe Boot"-like separate mini-install of Windows that is present on all applicable Windows systems. And because WinRE can be invoked by anyone with physical access to the device, anyone with physical access (and the knowledge) can now bypass Bitlocker.

And since WinRE is not patched by the Windows Update process, the only way to mitigate the threat is to create a separate process/script to locally apply the patch to each system currently running Bitlocker - or potentially running Bitlocker in the future - using the command-line mounting and WinRM steps provided by Microsoft.

In other words: anyone expecting Bitlocker to protect sensitive information (on a stolen laptop, etc.) needs to develop, test, and deploy a script to apply this fix.