Please, refer to this Wikipedia article if you need some theory… My paper is here.

Background: attacks on AES-CBC

Do you remember code execution attacks against full-disk encryption implementations using AES-CBC? Like that one described in the “Code Execution In Spite Of BitLocker” article or another one detailed in the “Practical malleability attack against CBC-Encrypted LUKS partitions” post.

In these attacks, physically-present adversaries manipulate ciphertext blocks to flip specific bits in the decrypted form, thus constructing code execution payloads to be executed on the next boot. This is not a direct payload injection, since the attackers don’t actually write their “raw” code into the encrypted volumes, but rather flip the bits belonging to existing executables in order to transform their code.

Such an attack consists of two stages:

• finding the exact position of bits to flip;
• flipping these bits (in a way that turns original code into attacker-chosen code).

The nature of AES-CBC makes it easy to flip bits in the decrypted form, because each block of plaintext is XORed with the previous ciphertext block before being encrypted:

In other words, the attacker can flip arbitrary bits in one block at the cost of randomizing the previous block.

(Source.)

The hardest part here is finding the exact blocks of ciphertext to manipulate. In order to inject custom code, the attacker must know what code to modify (i.e., its plaintext bytes) and its precise location on the disk. Otherwise, flipped bits won’t produce meaningful plaintext changes (since Attacker-chosen code = Original code XOR Delta, the attacker must know Original code and then produce Delta to obtain Attacker-chosen code).

Currently, the demonstrated bit-flipping attacks rely on predictable locations of executables. The attacker installs the same operating system version on similar media to learn the disk offsets required (this is based on one assumption: two operating system installations on similar media write at least some executables to the same disk offsets). According to the “Code Execution In Spite Of BitLocker” article:

In our testing, two installations of Windows 8 onto the same format of machine put the system DLLs in identical locations. This behavior is far from guarenteed, but if we do know where a file is expected to be, perhaps through educated guesswork and installing the OS on the same physical hardware, then we will know the location, the ciphertext, and the plaintext.

Obviously, this won’t work with operating system installations that are not “fresh”… Months (or even years) of operating system updates, their installation order, and many housekeeping activities are likely to move executables to unpredictable offsets, undermining the idea of predictable locations.

Thus, the most important part of the attack – finding the exact location of bits to flip – is extremely hard to complete in reality.

Concerns: attacks on AES-XTS

Bit flips through ciphertext manipulations are impossible with AES-XTS (and this is why this mode is preferred over AES-CBC when encrypting storage devices).

In this mode, any change to a ciphertext block will turn its decrypted form into garbage and won’t affect any preceding or subsequent blocks.

More than 15 years ago, Niels Ferguson and Vijay Bharadwaj argued that code execution payloads are still possible with AES-XTS:

The attacker now replaces the first few bytes of the ciphertext block and hopes that the randomized plaintext decrypts to a value such that the first instruction executed in the block is a jump instruction to the epilog code. On the x86 a relative jump instruction is 2 bytes long and can jump up to 128 bytes forward. The probability of getting the right plaintext is one in 2^16; high enough for a practical attack.

(Source.)

In other words, attackers can get specific byte values even through unpredictable (random) ciphertext manipulations.

Practical attack: CVE-2025-21210 vs. BitLocker & AES-XTS

The idea is to force the Windows operating system to write some sensitive data to the underlying drive without encrypting it first (i.e., to leak data in the plaintext form).

Continue reading “CVE-2025-21210 aka CrashXTS: a practical randomization attack against BitLocker” →