[bri3d]

Previously discussed numerous times on HN, like: https://news.ycombinator.com/item?id=48130519

Whether this is a backdoor or not boils down to whatever your usual proclivities about "bug or backdoor" are; it's not like "if microsoft = 1 hack bitlocker" like the tech press seem to love to report.

This is a bug in the NTFS transaction log replay functionality in the Windows Recovery Environment WinRE, where it will read NTFS transaction logs from an external volume and apply them to the mounted filesystem. This allows the attacker to perform an authentication bypass against WinRE. With BitLocker without PIN or Password, _any_ authentication bypass becomes a disk encryption bypass, since the disk is unsealed by the bootloader (this architectural "flaw" is true for Linux with the same configuration, as well, like Ubuntu installed with their newish Hardware Disk Encryption checkbox in the installer).

In lieu of additional evidence, whether you think the NTFS transaction log issue is a planted backdoor or a simple enumeration bug depends on your conspiracy theory level, like most things in exploit development. To me, it seems like a plausible bug. The weaknesses in boot-time unseal are well known and obvious and this is just one of many, so I don't see it as an earth-shattering revelation, although it is a fun bug.

[bastawhiz]

It's very strange that the same component exists in Windows without the issue, though. Like the author, I'm finding it difficult to come up with reasons why they'd be different.

[bri3d]

WinRE ending up with a different version of fstx.dll in it seems like a pretty standard Microsoft (or any other big company) thing to have happen? Again, it all comes down to whether you think the drift was a malicious internal fork or a simple mistake. I will say that the functionality being different makes it an inferior backdoor in many ways; especially in Windows land vulnerability researchers are obsessed with binary diffing, and any delta internally would be more likely to be discovered as a backdoor in review too (ie - “hey maybe we should update fstx in winrt finally, let’s review the drift to make sure there’s not going to be a regression, wait a second why did xyz employee add this suspicious looking code”).

A fun next step would be to look at different fstx versions to see if it’s just something that was patched or refactored out at some point. At that point it could be a patch-door (ie an organic bug where the patch was held back by interference), but again, that would be a crappy setup due to the propensity for Windows vulnerability engineers to use binary diffing - if you had the exploit and the power to hold back the patch, it would be way better to hold it back everywhere.

[bastawhiz]

I'm not necessarily suggesting they intentionally made the dll different for RE. The possibility that RE was maliciously backdoored is certainly possible, but there are three plausible other possibilities I can see:

1. A bug was introduced that affects both, and the bug never make it back into the 11 branch

2. There's conditional logic in RE that triggers the issue

3. 11 introduced new behavior that never make it to RE, causing the bug

The fact that 10 is seemingly unaffected is telling. #2 seems very unlikely, because it suggests new conditional logic was added and not tested. #3 seems unlikely because I can't understand why the binaries would be different anyway. #1 seems unusual because it suggests there's no canonical source of truth for the code, which feels very unlikely for bitlocker of all things (where you want everything speaking the same language).

If there's any benign explanation, I suspect it's likely due to incompetence. This feels like such a strange problem to have. I suspect the follow-ups you suggest are going to happen very soon and we'll know more.

[solenoid0937]

The author says he is able to use a similar vuln to bypass the PIN requirement. Most certainly a backdoor if true.

[bri3d]

I discussed this at length in the last thread: https://news.ycombinator.com/item?id=48137059

We know how PIN-locked BitLocker works, and it requires unwrapping using a key sealed behind a TPM PIN policy and stretching it using the PIN itself. So we can deduce that this would require that:

* The attacker was able to bypass the TPM PIN sealing policy _and_ brute-force the stretching applied to the decrypted key. Brute-forcing the stretch is plausible on a "lots of expensive stuff" timeline but not an easy attack. Bypassing TPM PIN policy across multiple platforms would be something quite incredible. Given that TPMs are implemented by multiple vendors across multiple fundamental architectural approaches, and aren't based on a universal reference implementation, it would be rather bizarre to find a mistake in many or all of them.

* There is a secret volume key stored on a volume which can be decrypted by another mechanism. This would be a backdoor, but seems vanishingly unlikely given the amount of research which has been applied against BitLocker historically.

* The attacker is at some point able to inject something which allows them to observe the victim applying the PIN. There could be an attack here but it isn't nearly as interesting.

[ChocolateGod]

> Most certainly a backdoor if true

If Microsoft wanted a backdoor they don't need to put it in the WinRE environment. They can sign payloads that will pass the TPM and unlock bitlocker, without needing to store anything on your disk.

[ranger_danger]

Except with TPM+PIN, the TPM itself is verifying the PIN before unsealing any keys... so something else must be going on if they're telling the truth about a PIN exploit.

Maybe their alleged exploit doesn't work on a cold boot or has some other non-standard situation.

[866-RON-0-FEZ]

This is the most succinct, plain-English explanation I've seen to date. Thank you for posting this.