For many years, Windows systems have been deployed without concern for the space required to house the various partitions that will be required during a routine installation. Many organizations use a routine deployment script that sets partitions with a certain size and standardization of drives. Indeed, many operating systems will likely be procured from a vendor that employs a standard build.
It’s rare that much attention gets paid to recovery partitions — where they are on a drive, or even whether they were necessary in the first place — which is unfortunate, considering the security risk they can pose. A case in point is a recent patch that fixes an issue that results in a vulnerability in the recovery partition which would allow an attacker to bypass BitLocker encryption and gain access to the drive without guessing or brute-forcing the encryption recovery key.
Recovery partitions can provide options for the repair of misbehaving systems. They allow IT administrators to boot into a basic operating system to employ tools or make repairs. However, some organizations opt not to deploy them as there is a history of attackers gaining access to systems underneath the operating system, where they can reset the OS or perform other nefarious tasks merely with physical access.
A vulnerability that sidesteps BitLocker
BitLocker is a Windows security feature that allows for the encryption of entire volumes, protecting against data theft or exposure from lost, stolen, or inappropriately decommissioned devices. It’s a robust solution for protecting laptops and other computer systems, but it brings with it additional overhead of deployment, management of recovery keys, and other deployment issues.
But now, patching for this issue has brought along additional risks. CVE-2024-20666 and its related patching has pointed out a longstanding position of mine — sometimes the patch triggers more risk to the network than the vulnerability does. In other words, the potential side effects of the update, in this case enabling bad actors to get around BitLocker, are vastly greater than the vulnerability we are protecting ourselves from.
To patch this vulnerability, Windows 10 has a separate patch KB5034441. The Windows 11 version is included in the Windows 11 cumulative update. Equivalent versions are also needed for supported Windows Server operating systems.
The update will attempt to patch the recovery partition, but here lies the problem: Over the years Microsoft has changed its mind on how big the recovery partition should be and exactly where it should be located. Depending on how old your deployment images are, that is when you first installed your base of Windows 10 machines, and if you haven’t redeployed operating systems, you may find that many of your installed systems will fail to install this update.
Managing vulnerable disk partitions
If you have no recovery partition, your system is not at risk from this vulnerability, but the update will fail, nonetheless. Microsoft has stated it is working on a fix for this issue in an upcoming release. If you have a recovery partition but it doesn’t have enough free space — a minimum of 250 MB — this too will trigger the update to fail.
If your recovery partition is to the left of the C drive in your deployments, resizing the recovery partition may not be able to be accomplished without a great deal of redeployment planning. If the recovery partition is to the right of the main C drive, then you can use scripts to shrink down a bit of the main C hard drive and assign the space to the recovery partition allowing the update to succeed.
In the past, even Microsoft has made changes in their documentation to when and what disk configurations are most important. In a test of several drive configurations at my office I found a mixture of systems that had no recovery partitions. These I flagged as having the potential for outright failure but not vulnerable to the security vulnerability. Next, I found a series of devices that gave me confusing drive specifications.
Susan Bradley
In the Drive management console, I found systems that had two recovery partitions, one in front of the C drive and the other behind it. In these systems, I found that it was the partition behind the C drive that was still the one that the system had in use. I was able to determine this by going into an Advanced PowerShell window and typing in reagentc/info. This provided the identification of the partition that Windows saw as the active recovery partition.
Susan Bradley
Don’t be fooled by the report that the recovery partition is 100% free. In reality, when using a partition tool, the free space in partition is vastly under the recommended 250 MB free. In fact, many configuration specialists are now recommending a configuration that begins the deployments with at least a 1 GB recovery partition. This will give enough space for future patching of this special partition.
Options for fixing Windows partition issues
What options do you have? Scripts are available to guide you on moving the impacted partitions but with any major project they need to be tested and analyzed for your environment. You may decide to hide the update on your Windows 10 platform — the operating system most impacted by these failures — and revisit this issue later by redeploying your Windows 10 instances if you feel the risk of this vulnerability is acceptable. Many will likely be planning the replacement of Windows 10 deployments before Microsoft stops supporting the older OS in 2025.
An attacker would have to have full physical access to the devices, and you could plan on remediation such as physical locks or other processes to ensure the security of the impacted devices. You will have to inform management and/or your vulnerability scanning vendors of your intentions to bypass this update in the meantime.
Ultimately, you need to discuss partition allocations with your vendors and deployment specialists. Autopilot requires a recovery partition for auto wipe and will not allow you to deploy it effectively without a properly sized recovery partition. Thus, you may need to review the autopilot configurations you are using and start standardizing on a 1-gigabyte recovery partition to futureproof any patching that Microsoft may need to do in the future of this small under-the-operating-system drive partition.
Partitioning decisions were once such a mundane item that you never thought about the details. It was either the operating system that installed what you needed, or your OEM gave you a standard build. Now that decision to “just take the defaults” may cause you to have to run additional scripts at best, or redeploy existing Windows 10 devices at worst. These deployment decisions are building blocks that the entire network is based on. Ensure that you’ve devoted enough resources to get the decisions right the first time.