Whenever you install an application on Windows, typically through MSI, there is a registry key created, with plenty of information for uninstallation, like the uninstaller location, install date, publisher, etc… you can find all of the options here: Add uninstall information to Add/Remove Programs - NSIS
In case an application is installed for the current user and not for all user, the Installation/Uninstallation details will go to the Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key instead of the HKLM hive. For example OneDrive has all the information under the following registry key: Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\OneDriveSetup.exe
Under this key we can find the following values, that could point to an executable:
UninstallString
QuiteUninstallString
ModifyPath
As these settings are under the user’s registry hive he/she has the rights to modify it and set a custom value. Setting a custom executable here could result in a privilege escalation scenario if the person (likely an administrator) running the uninstaller, and entering his / her creds is unaware of the change. This happens because Apps & Features behaves differently from Control Panel. For example, let’s set it to cmd.exe with OneDriveSetup.exe (which exists normally by default on most installations):
If we run the uninstall through the Control Panel, it will execute the process with the current user’s rights. So in the above case we get a command prompt running as the user. If the application we choose has the requireAdministrator set in its manifest, it will still prompt for password, but Control Panel - more precisely appwiz.cpl will only try to elevate the rights before execution if the registry value is taken from the HKLM hive. In other words, if you uninstall something, where the settings are coming from HKLM Control Panel will try to elevate the rights, otherwise not. This is good.
However if we try to uninstall this app from the System Settings -> Apps & Features, it will try to execute the referred application with admin rights.
The user will get a UAC prompt upon clicking Uninstall. The prompt will mark what is executed (like in the case of cmd.exe it will show that it’s trying to execute the Windows Command Processor), however before that there is no indication what will be executed (as we can see above). The same behaviour is observed if we set the ModifyPath value.
I think this behaviour is inconsistent, and if the user has the rights to set an executable path, later on it shouldn’t be tried to be executed with admin rights. Yes, the user will get a prompt to enter an administrator password, however it makes it very easy to trick someone.
I contacted MSRC about this, and they said that the observation is valid, however they don’t consider it as a security bug, however they might fix this in the future.