winget-cli
winget-cli copied to clipboard
microsoft
Cannot override installer hash as admin. Even if EnableLua = 0 (UAC OFF)
Cannot override installer hash when running as admin, even if EnableLua = 0 (UAC OFF)
I want to install the package. Please let me install the package.
Steps to reproduce
Try to install a package with a mismatched hash while running as administrator.
Expected behavior
It allows you to install.
Actual behavior
It does not allow you to install.
Edited:
This feature is to track the work to have an administrator required setting to enable the ability to override a hash mismatch.
It would be something like winget settings --enable ignore-security-hash-argument.
The group policy on "--force" will need to be evaluated and potentially modified or a new one added for this use case.
There should be a separate argument required for "--ignore-security-hash" rather than "--force" which would work in both user and admin modes if the setting is enabled.
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.
Yes, when I use --force I get the following error still: "Installer hash does not match; this cannot be overridden when running as admin"
Note that when using an admin account and running Windows with EnableLua=0, all applications run with full privileges. This turns UAC off. It would be nice if the hash override would remain available to users running with this configuration. Fwiw, I have never encountered a feature in any Microsoft product that did not work with this configuration, except as a bug.
Hi, is there any reason why this feature is disabled at all for users running as admin? This seems to be upside-down. Usually, running as administrator gives you more privileges, not less.
I also just want to reiterate that when you turn UAC off on a machine, it's impossible to not run as admin, so the hash override feature becomes completely unavailable.
If you are running as administrator and the installer on the other end is compromised, it can do whatever it wants to your system once winget runs it. If you aren't running as administrator and do --force, UAC should pop up and say "hey, this application wasn't signed by a vendor. run anyway?"
It should be configurable via winget settings, but by default winget shouldn't be allowing people to easily run unverified binaries (since if there is a hash mismatch, it means that the version that winget downloaded wasn't verified through the community repo and therefore could be a virus or something).
I also just want to reiterate that when you turn UAC off on a machine, it's impossible to not run as admin, so the hash override feature becomes completely unavailable.
This is good default behavior. The only reason hash overrides are really needed right now are because the manifest update time is so long, but once the bots get better and we have other repos to choose from this shouldn't be much of an issue.
We're looking at several options to deal with this scenario. There have been several concerns about having command-line overrides that could potentially result in malicious code getting installed by the Windows Package Manager (eg. copy-paste this command from some "bad actor").
A few options have been suggested:
Have a setting requirement to enable the capability (enables a Group Policy to block behavior by IT administrators). Change the value to something other than --force (something more akin to --IgnoreSecuritysha256).
Generally, it is preferred not to ignore security checks. Are there any other suggestions here?
I don't think you need to have that concern. There are any number of things that if you copy and paste into a administrator command prompt will absolutely trash/compromise/etc. your computer. An admin command prompt can do anything on a Windows machine (even perform an escalation to SYSTEM). So I don't see a point in being concerned about it in this one small case. Especially if someone has turned off UAC.
We now have a Group Policy to determine if the ability to override hash validation is available to users. We are discussing adding a setting to the "settings.json" file to "enable the ability to --force". Once that is in place we can allow either a user or an administrator to override the hash validation.
I'm converting this bug into a feature to capture the work.
Related: #714
Question: I'm trying to automatically install Google Chrome in a post-install script. The script is running as the SYSTEM user, since it is being invoked by the operating system on the first boot. When I execute the following command:
winget install --accept-source-agreements --silent --exact --id Google.Chrome --force
It fails with the following error message:
Installer hash does not match; this cannot be overridden when running as admin
(As previously mentioned in this issue.)
As a workaround, I tried performing the following:
runas /user:james-pc\james "winget install --accept-source-agreements --silent --exact --id Google.Chrome --force"
This works, but it requires that:
- The end-user manually types in the password of the user that they are using with
runas. - A UAC notification pops up that must be manually clicked on.
Thus, this is not a viable workaround, since the point of this script is that it will automatically install Google Chrome without any user intervention.
Does anyone else know of any other workarounds to this problem?
In conclusion, I definitely have to agree with MarcoPeraza: "automatically installing Google Chrome" is probably one of the most basic things that one would expect a competent package manager to do. So the fact that winget may not be able to perform this right now is a glaring hole in its functionality.
Any other way to work around it would probably be a bug in UAC.
The actual solution to your problem is that we need to be better about updating Chrome and Spotify (the two apps that change their installer hashes most often) in the community repo. I just saw the PR for it had been sitting for 24 hours or more before a moderator got it approved (oops), then it sat for another hour until the bot got it merged. I've gotten lazy due to the community automation being better than it used to be, but it still misses Chrome updates a bunch. Sorry for the trouble.
We've been discussing the behavior for the hash override behavior. "--force" doesn't really convey that you are taking a risk in installing a package when the hash doesn't match. I think we're leaning towards an administrative setting to enable the hash override. Then we will need to enable this mechanism to work both for user and admin modes as some programs don't work when installing under one or the other mode. We will also need to put out a very clear warning about the fact that the hash was ignored.
Any other way to work around it would probably be a bug in UAC.
Is this actually true? For reference, the analog in Linux would be running the following command as root:
runuser -l james -c "winget install --accept-source-agreements --silent --exact --id Google.Chrome --force"
If I performed this command in Linux, it would notably not prompt me for the password of james. And this behavior does not violate the security model, because I already am the root user and therefore should have full access to the system. (As a simpler example, consider that if typing passwd james as the root user prompted me for the existing password of james before letting me assign a new password, that would be absurd.)
The specific issue here is that the runuser command is not a perfect analog to the runas command. Specifically, the latter seems to forget the context of how it was invoked, where as the former is a bit smarter.
All I mean to say by this is that a temporary workaround for the Google Chrome issue seems like it could exist, in principle, with something other than the runas command.
It could exist, you're right. But an easier place to fix it would be in winget. Windows only lets you impersonate a user if they are currently logged in, and if you know their password (PsExec would probably also work to do what you want, but you'd need the user's password to be entered just like runas).
The traditional *nix way of root knowing everything about everything makes life easier, which is why I still prefer using Linux for running servers and things. But I think the design assumption Microsoft made was the correct one ("why would someone need to impersonate a user without their permission? if they do have permission, the target user can definitely type their password in"), as under most cases people in the Administrators group can access all user's files/settings/etc, they just can't pretend to be that user while doing it.
The actual solution to your problem is that we need to be better about updating Chrome and Spotify (the two apps that change their installer hashes most often) in the community repo. I just saw the PR for it had been sitting for 24 hours or more before a moderator got it approved (oops), then it sat for another hour until the bot got it merged. I've gotten lazy due to the community automation being better than it used to be, but it still misses Chrome updates a bunch. Sorry for the trouble.
As long as there's any lag time at all during which the package is broken, then it's hard to use winget for any serious scripts. I don't see how an approach focused on shortening that time period, instead of eliminating it, can get you there.
I would argue that running "serious scripts" where there's no hash validation of binaries that may be running on important systems would make it hard to use winget though. I think if we can get to where brew is, where packages are updated within an hour or two of the ISV updating their server, we'll be in a healthy spot. (I'm pretty sure the reason brew can do that is a mixture of analytics from the client and good community participation, and we can get at least one of those easily.)
I see the point regarding verification of binaries. But Microsoft has a very good code signing system baked into Windows that winget could leverage to provide those same guarantees.
Maybe another way of putting it: what attack are you protecting against? Someone taking control of the software vendor's download URL and replacing it with malicious software? In that situation, users are screwed anyway. 1) auto-update mechanisms in the software are likely compromised too and 2) the user's likely recourse after winget failing is to go to the vendor's website... and download that same binary, and 3) they would also need to have compromised the code signing certificate. Like Raymond Chen says, "it rather involved being on the other side of this airtight hatchway".
I set up a new machine today, and again, Google Chrome could not be installed due to a hash mismatch.
I set up a new machine today, and again, Google Chrome could not be installed due to a hash mismatch.
Can confirm. Google Chrome won't work, even with "--force" flag when running as Administrator. Without admin it works fine with "--force" flag
Same Problem for us, chrome wont install because of mismatch that cant be overwritten as admin
And I want to add that the same goes for Logi Options+ & Hardcopy
EDIT: Logi Options+ works for now
I don't think you need to have that concern. There are any number of things that if you copy and paste into a administrator command prompt will absolutely trash/compromise/etc. your computer. An admin command prompt can do anything on a Windows machine (even perform an escalation to SYSTEM). So I don't see a point in being concerned about it in this one small case. Especially if someone has turned off UAC.
I agree with this position. I don't feel its up to winget to decide on the security of the operating system. That is up to the overall security configuration deployed within an enterprise. There are multiple layers there already including but not limited to ASR. App Control and coming soon PIM solution for adminstrator elevation.
Although, I do like the hash confirmation and feel a --force would be a nice solution.
I do like the idea of the hash safety.
If we wanted to be super paranoid about security then perhaps have a fallback manifest setup so you can potentially install an exe where the hash matches.
I have this issue right now with Microsoft.PowerBI
So if even Microsoft can't keep up with hash updates it seems to me the issue here we need to solve is updating of manifests in a quicker manner.
I see the point regarding verification of binaries. But Microsoft has a very good code signing system baked into Windows that winget could leverage to provide those same guarantees.
Maybe another way of putting it: what attack are you protecting against? Someone taking control of the software vendor's download URL and replacing it with malicious software? In that situation, users are screwed anyway. 1) auto-update mechanisms in the software are likely compromised too and 2) the user's likely recourse after winget failing is to go to the vendor's website... and download that same binary, and 3) they would also need to have compromised the code signing certificate. Like Raymond Chen says, "it rather involved being on the other side of this airtight hatchway".
This got me thinking too, we use Defender and Sentinel in our enterprise. Microsofts AI driven security system is extremely powerful, I would have thought if winget was becoming a core component of Intune that its Microsoft's intension to ensure the backend is protected by these same systems MS offers to enterprise and you'd have some kind of mechanism where Defender scans the manifests, downloads the executables and compares the hash against its Threat Protection system?
WinGet operates in several differnt kinds of environments. This issue is really about how we initially implemented the hash override mechanism. We agree it needs to change, but it's considered a breaking change which would require a "major" version bump.
This is actually the current top reason we would consider that activity. We're compiling a list of other potential reasons to justify a major version bump. It's not something we take lightly, and we also want to be very explicit about other changes being considered:
- https://github.com/microsoft/winget-cli/issues/2128
Ran into this when users started to complain that they can't install Chrome via the Company Portal today which of course let to the discovery that a new version has been released but the repo is lagging behind.
I built a script that invokes winget under the SYSTEM account and runs the params to install the app and I assumed that I could mitigate the issue specifically for Chrome by using --force since it should override the hash check but strangely it doesn't.
Since Google deploys new versions of Chrome so frequently this is an issue that keeps popping up. Either Merge requests for Chrome should be handled faster (since it's such a popular app this shouldn't be hard right? or --force should actually do what says it does: override the hash check and install it anyway. I'm aware of the risks and if the Chrome installer is compromised I think we got bigger issues on our hands.
@Skeb1ns I am Using the great tool "WingetAutoUpdate" in my company, which lets you set a "Blacklist" for auto updates. For me in the blacklist are Chrome, Teamviewer and Office apps. Maybe that helps you.
To deploy winget apps I am using winget-install which works fine for me with Intune
