Closed DRLDoom closed 7 years ago
So an option to disable the check seems like the wrong approach here which will disable security features because of an algorithm issue (with an algorithm which has no actual weaknesses but is just a certificational FIPS issue).
In this case your workaround is a more appropriate workaround and is more in line with official recommendations from microsoft: https://blogs.technet.microsoft.com/secguide/2014/04/07/why-were-not-recommending-fips-mode-anymore/
There's a bug here though which is that there definitely are FIPS-compliant SHA256 algorithms that can be used to do this work. Its likely the problem here is entirely certificational and that the particular implementation we're using has not been blessed with FIPS, while other numerically equivalent algorithms are so blessed, and we should be using the latter.
However, this is all a bit over my head, since I'm both not a Windows expert nor a FIPS expert.
This is where the SHA256 check happens and any fix should probably hit this line (and the similar line somewhat above it):
This bug looks like it discusses this situation:
https://github.com/IdentityServer/IdentityServer3/issues/571
This issue is also now resolved in .Net 4.6.2. Prior to .Net 4.6.2, SHA256.Create() defaulted to using SHA256Managed. In .Net 4.6.2 they changed it to use SHA256Cng. dotnet/roslyn#15939
I agree with @lamont-granquist that this should be fixed over in https://github.com/chef/mixlib-install.
It actually is likely to be simply changing
New-Object -TypeName Security.Cryptography.SHA256Managed
to
New-Object -TypeName Security.Cryptography.SHA256Cng
This should be fixed by https://github.com/chef/mixlib-install/pull/220 when it gets released to omnitruck.
Cookbook version
2.0.1
Chef-client version
12.17.44 to 12.20.3
Platform Details
Windows Server 2012 R2 - AWS
Scenario:
Attempting in upgrade Chef-client on a Windows Server 2012 R2.
Steps to Reproduce:
Our systems are hardened per DISA Stigs. Which is preventing the SHA256 hash check call in the install powershell script.
You can replicate the issue by setting the below registry key to 1. If set to 0 the powershell SHA256 check will work.
Calling the resource like this:
Expected Result:
Successful run with the checlient being upgraded to 12.20.3.
Actual Result:
Workaround
For a temporary workaround I am using this: