this post was submitted on 22 May 2026
302 points (99.7% liked)

PC Master Race

21221 readers
27 users here now

A community for PC Master Race.

Rules:

  1. No bigotry: Including racism, sexism, homophobia, transphobia, or xenophobia. Code of Conduct.
  2. Be respectful. Everyone should feel welcome here.
  3. No NSFW content.
  4. No Ads / Spamming.
  5. Be thoughtful and helpful: especially when new beginners have questions.

founded 3 years ago
MODERATORS
_MoveSwiftly@lemmy.world
Brunbrun6766@lemmy.world
IowaMan@lemmy.world
BobaFett26@lemmy.world
The_Vampire@lemmy.world
Fudgeknuckles98@lemmy.world
CatZoomies@lemmy.world
Xeon@lemmy.ml
302
Microsoft issues mitigation for critical Windows 11 BitLocker flaw exploited with a USB key — "Can't come up with an explanation beside the fact that this was intentional." (www.windowscentral.com)
submitted 4 days ago by sanitation@lemmy.radio to c/pcmasterrace@lemmy.world
36 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] Wildmimic@anarchist.nexus 132 points 4 days ago* (last edited 4 days ago) (2 children)

lol

Microsoft:

In the meantime, Microsoft recommends changing BitLocker’s configuration on encrypted devices from TPM-only mode to TPM+PIN mode using PowerShell, the command line, or the Control Panel. This adjustment requires a pre-boot PIN to decrypt the drive at startup and is expected to block YellowKey attacks.

Chaotic Eclipse posted the following with the disclosure of Yellowkey:

Second thing is, No, TPM+PIN does not help, the issue is still exploitable regardless, I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I'm just not publishing the PoC, I think what's out there is already bad enough.

Additional info:

The YellowKey is caused by the binary "autofstx.exe" which propagates all present volumes for transaction files, a researcher (unsure if they want to be named) told me that this binary is also present in windows update WinRE images and I think they will definitely have the same vulnerability as well. However, I'm unsure if it's possible to trigger the controlled file deletion when windows is updating. If it's true, then it means disabling WinRE is not a solution for the problem, which also means it's a good thing that I kept the PIN+TPM PoC a secret.

And as response to this:

"Microsoft is aware of a security feature bypass vulnerability in Windows publicly referred to as "YellowKey". The proof of concept for this vulnerability has been made public violating coordinated vulnerability best practices."

They posted:

Saying that I violated CVD best practices is a defamation of my personal reputation, you already told me you will defaming me and doing it in public will not help dissolve this conflict. You intentionally revoked my access to my MSRC account that I used to report vulnerabilities to you, when I asked you, you went ahead and completely wiped the account from existance despite multiple attempts from asking for an explanation. All of those requests went unanswered by the MSRC leadership.

I'm taking your statement very personally.

I have to say, i'm a fan.

Edit: The story so far would probably be well suited for an anime adaption. I hope we learn someday what shit MS pulled to make our friendly neighborhood security researcher so pissed that they started a one-person-crusade against one of the largest IT companies in the world.

[–] Wildmimic@anarchist.nexus 76 points 4 days ago* (last edited 2 days ago)

Even better, they posted this last week:

After re-investigating the technique used in GreenPlasma (specifically SetPolicyVal), it turns out cldflt!HsmOsBlockPlaceholderAccess is still vulnerable to the exact same issue that was reported to Microsoft 6 years ago. I'm not taking full credit for this, James Forshaw from google project zero found the vulnerability and reported it to Microsoft and was supposedly fixed as CVE-2020-17103.

However, a research who's a friend of mine pointed out that the routine might still have a vulnerability, which is something I considered but brushed off because I thought it was impossible for Microsoft to just not patch this or rollback the patch.

After investigating, it turns out the exact same issue that was reported to Microsoft by Google project zero is actually still present, unpatched. I'm unsure if Microsoft just never patched the issue or the patch was silently rolled back at some point for unknown reasons. The original PoC by Google worked without any changes.

https://gitlab.com/nightmare-eclipse

https://deadeclipse666.blogspot.com/

Edit: Microsoft deleted the github, updated link to new gitlab repo

[–] raspberriesareyummy@lemmy.world 14 points 4 days ago (2 children)

Chaotic Eclipse posted the following with the disclosure of Yellowkey:

Second thing is, No, TPM+PIN does not help, the issue is still exploitable regardless, I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I’m just not publishing the PoC, I think what’s out there is already bad enough.

Additional info:

The YellowKey is caused by the binary “autofstx.exe” which propagates all present volumes for transaction files, a researcher (unsure if they want to be named) told me that this binary is also present in windows update WinRE images and I think they will definitely have the same vulnerability as well. However, I’m unsure if it’s possible to trigger the controlled file deletion when windows is updating. If it’s true, then it means disabling WinRE is not a solution for the problem, which also means it’s a good thing that I kept the PIN+TPM PoC a secret.

Would you happen to have a source link for those claims? I'd like to forward them to a few organisations I work with, warning them that devices currently lost/stolen/left unsupervised despite having TPM+PIN configured will have to be considered compromised even if a future patch comes out.

[–] Wildmimic@anarchist.nexus 24 points 4 days ago* (last edited 2 days ago) (1 children)

it's the second link, https://deadeclipse666.blogspot.com/ - The entry is from May 13, titled "We're doing silent patches now huh, also a quick note about YellowKey", the second part is from May 14, titled "Important updates regarding YellowKey and GreenPlasma". They are the one who found the vulnerabilities, PoC for RedSun, BlueHammer, YellowKey, GreenPlasma and MiniPlasma are on Gitlab @ https://gitlab.com/nightmare-eclipse

[–] raspberriesareyummy@lemmy.world 1 points 3 days ago

Thank you - it appears I stopped reading just one comment short of that, assuming that the "TPM+PIN is insecure" was a new comment, and not expecting it deeper down in the past.

[–] SpaceCadet@feddit.nl 3 points 2 days ago* (last edited 2 days ago) (1 children)

Second thing is, No, TPM+PIN does not help, the issue is still exploitable regardless, I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I’m just not publishing the PoC, I think what’s out there is already bad enough.

The PoC for that goes to another school, in Canada.

Edit:

Downvoters don't understand the nature of this exploit.

Without PIN, the windows recovery software has full access to the encryption keys in the pre-boot environment. So to crack bitlocker in this case, a hacker only needs to find a bug in the WRE to get at the keys. => That's the Yellowkey exploit.

With a PIN, no Windows or Microsoft program has access to the bitlocker encryption keys until the PIN is provided, and it can't be brute forced because the TPM protects against that. To exploit that, would require a attack on the TPM hardware itself, which would be absolutely massive if he could pull this off through software only and of a completely different nature than the Yellowkey exploit. It also wouldn't have anything to do with Microsoft software, because it wouldn't be in the loop for this.

To use an analogy: Yellowkey is like beating a bank employee (the WRE) who knows the combination to the safe with a wrench until he gives you the combination. In an attack with a PIN, the bank employee doesn't know the combination himself, so you can beat him with a wrench as much as you like, he's not going to give you anything useful.

Extraordinary claims require extraordinary evidence, and he has provided none. Furthermore, he has a bone to pick with Microsoft over a denied bug bounty, so he clearly has a motif to undermine trust in Microsoft products like bitlocker. All this, and knowing the typical hacker personality, leads me to believe that this is pure bluff. If he had something, he would show it.

[–] raspberriesareyummy@lemmy.world 1 points 1 day ago (1 children)

That clarification of yours is massively important. Your initial comment sounds as if there is a PoC from Canada on how to circumvent the PIN for the Bitlocker keys.

Maybe that's why you got downvoted?

I agree the "security researcher" sounds bitter, but also they found a proven critical backdoor, so it'd be negligent to just ignore their comment about circumventing the PIN. And the only way they could put microSLOP at fault for that would be if they could find that microSLOP was backing up encryption keys in the recovery environment / boot files somewhere.

[–] SpaceCadet@feddit.nl 3 points 1 day ago* (last edited 1 day ago) (1 children)

That clarification of yours is massively important

I think my mistake was assuming I was on a security related community, where this would be understood, instead of PC masterrace.

Your initial comment sounds as if there is a PoC from Canada on how to circumvent the PIN for the Bitlocker keys.

It's a meme joke, referencing this: https://knowyourmeme.com/memes/she-goes-to-another-school

the only way they could put microSLOP at fault for that would be if they could find that microSLOP was backing up encryption keys in the recovery environment / boot files somewhere

Seems unlikely. The WRE is like 32MiB in size, and most of that consists of static binaries. Not much info is saved there, except for some log files. If the bitlocker keys were there, they would have already been found by someone else.

[–] raspberriesareyummy@lemmy.world 1 points 1 day ago

Seems unlikely.

That's what I'm saying. Not impossible though to hide key weakening info somewhere.