New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v2024.2.0: PowerShell Terminal Fails to Load Due to PSES change to non-Windows-trusted Certificate #4974
Comments
Since 2024.2.0 some components (DLLs and PS1/PSM1/PSD1) of the module are signed with a untrusted certificate/CA called "ameroot" - here is the output with sigcheck from Sysinternals, also affects AppLocker if you use application allowlisting: Signers: Microsoft Azure Code Sign Please MS fix this asap and sign this components with a trusted root CA - workaround is now to revert to V2024.0.0 - even the newer prerelease version has the problem with untrusted CA |
No certificates are trusted on your machine by default. They are signed with updated certificates, you will need to trust those when running AllSigned. |
See more info here: #3741 (comment) |
This issue has been labeled as resolved, please verify the provided fix (or other reason). |
That's not true - there is a list of Trusted root certificates which gets updated by Microsoft and Windows does download them automatically. That Root certificate ameroot is not an official root certificate - so you have problems with AppLocker. Issue is not resolved. |
Couldn't agree more. |
This issue has been labeled as resolved, please verify the provided fix (or other reason). |
Not resolved yet |
This issue has been labeled as resolved, please verify the provided fix (or other reason). |
@andyleejordan I can reproduce this on a clean Win11 box, though it's just silently failing for me with allsigned on even with all the verbosity turned on. The signing cert for PSES changed with the latest release, and it's not one that's trusted by Windows by default. Does this have to do with the build changes you made perhaps? |
Ahh well that was embarassing. There was a typo in our pipeline that lead to a silent failure to use the correct certificate, so it defaulted to "Microsoft Azure Code Sign" instead of what it was supposed to be set to, "Microsoft Corporation." And that only shows up as a problem in particular circumstances (as you all have found). Hotfix release is on its way with this resolved. Thanks @JustinGrote for pointing that out. #4977 |
This issue has been labeled as resolved, please verify the provided fix (or other reason). |
Ok v2024.2.1 is out and fixes this. Sorry! |
Confirmed fixed with v2024.2.1 and AllSigned on. |
@cyrkin thank you for persisting with additional information beyond our initial recommendation! Otherwise we wouldn't have caught it. |
Exactly. There have been recurring issues with |
Thanks, working nearly perfect except one DLL: AppLocker is still having a problem with the certificate(s) and counter signing of this file here: .vscode\extensions\ms-vscode.powershell-2024.2.1\modules\powershelleditorservices\bin\common\System.Reactive.dll The DLL "System.Reactive.dll" is counter signed from yesterday with a "Microsoft 3rd Party Application Component" certificate, but also still countersigned from the past in 2023 with the signer "Reactive Extensions for .NET (.NET Foundation)", which worked perfect in the previous version 2024.0.0 - could you please investigate this and sign it with only one certificate/counter signing? It's important to allowlist this DLL with publisher rule in AppLocker - thanks in advance. |
I noticed that when setting this up actually, and unfortunately the |
I see, but could the security engineers at Microsoft take a look because of AppLocker Application Allowlisting? Because with this new counter signed DLL a publisher rule doesn't work anymore, with the System.Reactive.dll from V2024.0.0 it works perfect - and all the other DLLs from the new V2024.2.1 work perfect with publisher rules, too. Thanks in advance, would be very happy when this issue could be resolved, security is very important for us |
@andyleejordan is the Reactive DLL a direct dependency or something transitive from |
As an aside, I found the reference to While we could unwind that, It is also referenced in OmniSharp.Extensions.JsonRPC as a transitive dependency
So we wouldn't be able to remove the assembly due to that entrenched dependency. |
The Reactive DLL hasn't changed but it may have been being incorrectly signed as Microsoft First Party when it is in fact Microsoft Community, that was my main query to @andyleejordan that may have been "fixed" but now breaks the ability for the extension to be wholly "pre-signed" on windows systems. This is more of a legal issue than a technical one, so I have to defer to Andy as to whether that DLL can continue to be signed as it was before since it hasn't changed, but future versions may still have the problem anyways. I imagine this may be a change in policy as supply-chain attacks such as Solarwinds, xz, etc. have probably made Microsoft extremely sensitive about these sorts of things. |
Reopening the issue to address |
You've written it out exactly Justin. When switching to the new signing system, it detected that |
This issue has been labeled as resolved, please verify the provided fix (or other reason). |
Maybe it is in fact having a problem with those other DLLs, it just is erroring and exiting first on reactive |
If i use the React DLL from V2024.0.0, where only ONE CERTIFICATE is in the DLL, it works perfect - with the new one from V2024.2.1 with TWO CERTIFICATES it doesn't work. If i sign it with my own code signer certificate, which is allowlisted in applocker, it works also perfect - and it has only ONE CERTIFCATE after i signed it. |
I have triple checked this, and it's correct as-is, and I am being required to dual-sign it. Please ask your admins to update their AppLocker rules to accept |
Thanks a lot for your checks and your comment - i'm also in the lucky position to be the admin for AppLocker rules, too :-) The AppLocker rule is correct and works with V2024.0.0, but the issue, as also mentioned here in the past, is the "dual signing" - AppLocker does only read the first certificate, not the second one if you make publisher rules. This is a main problem and design issue from the AppLocker mechanism, but this mechanism was designed from Microsoft back in 2007. In WDAC this is not a problem anymore, because WDAC reads all signatures from a PE file and does not rely on the trusted root store from Windows. I can confirm, as i'm also doing WDAC, that it works there without a problem. Here is the allowlisting publisher rule from AppLocker, it works perfect with V2024.0.0 and "single-signing" - the properties "Binaryname" and "Binaryversion" have a wildcard "*", so it does not rely on the version number of filename, only the Publisher and the productname of the PE File/Header: In the mean time i engineered further and did find out 2 things, which have a security impact for an enterprise environment with strict allowlisting: 1.) If you make a publisher rule that every publisher is allowed (wildcard for every publisher), it works -> not secure for an enterprise solution. 2.) If you make a publisher rule that every Microsoft signed binary is allowed (wildcard for Microsoft), it also works -> that enables also LOLBIN scenarios, that are also not secure enough for an enterprise environment. 3.) A file hash rule would work, but these are a problem if the DLL will be changed in a future release of the PowerShell Module, so it has an impact in the production environment and does not work for us. So it is a design problem from AppLocker, maybe Microsoft can repair this issue for Dual signed PE files, but i'm not sure if Microsoft will do enhancements for AppLocker, as WDAC is the future allowlisting mechanism for them. One final question because i'm curious: what is the reason for dual-signing a file, which hasn't changed from 2024.0.0 to 2024.2.1? Could it be single-signed with a new, fresh certificate? Thanks for the help :-) Update: i did resolve it with a "hack" - hope this will help some other AppLocker admins, too :-) Now you have to manually create 2 publisher rules with 2 different Publishers: 1st rule: Publisher: O=REACTIVE EXTENSIONS FOR .NET (.NET FOUNDATION), L=REDMOND, S=WASHINGTON, C=US 2nd rule: Publisher: O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US Of course you can tighten it with filename and version if someone want. These rules can be made manually in the GUI with custom editing of the Publisher string or with the PowerShell AppLocker module/commandlets with a prepared AppLocker XML rules file and i confirm it works now. The GUI (mmc.exe) cannot read the 2nd certificate, it's still a design flaw from AppLocker, but won't be repaired anymore i guess. |
That lines up with what I heard internally about AppLocker (that while it still exists, it's mostly been deprecated in favor of WDAC due to better security boundaries, and hence its lack of support for dual-signing). Essentially, with the migration to an internal build/sign/release system called OneBranch, I am required to sign all the libraries I ship. When those are signed with a third-party certificate already, I must counter-sign it with that Microsoft 3rdparty Application Component certificate. I don't really have a way around this, the pipeline fails otherwise. |
Thanks for the confirmation concerning depreciation of AppLocker, very useful information 🙏🏻 |
Prerequisites
Summary
Hello,
Since the extension updated itself to V 2024.2.0, I can't use the integrated Powershell terminal of my VS Code anymore, it won't load.
My ExecutionPolicy is set by GPO to AllSigned : it has always been like that, it worked like that, and it's not planned to change.
It's like the code in PSReadLine.format.ps1xml is now signed using an unapproved certificate on my side, or it tries desperately to force the ExecutionPolicy to change, which it did not do before.
When I finally kill the terminal, here's the output :
I rolled back to version 2024.0.0 and it works again.
PowerShell Version
Visual Studio Code Version
Extension Version
ms-vscode.powershell@2024.2.0
Steps to Reproduce
Visuals
No response
Logs
No response
The text was updated successfully, but these errors were encountered: