Vibe coded operating system what could go wrong
Vibe coding did not exist when this was put it in.
Oh then yes back door no other explanation plus them being very sus
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.
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://github.com/Nightmare-Eclipse/MiniPlasma https://deadeclipse666.blogspot.com/
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.
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 GitHub @ https://github.com/Nightmare-Eclipse
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.
This is what it looks like if lawmakers are allowed to pass legislation forcing back doors in encryption…but worse because it wouldn’t be just Windows.
Pray they don’t backdoor it again.
That’s not fair this could just be vibe coding there’s no way to know you know ms dogfoods copilot requires everyone code
Corpo software will ALWAYS have backdoors.
Can’t have those disgusting, smelly peasants locking their betters out of their home computer now, can we?
Of course they will. That’s why the actual “fix” will be in the next update. They first have to build a new backdoor before the old one is really closed.
