Restricting access to kernel-mode drivers

[cldy2nyt]

I have recently discovered that ThrottleStop's kernel driver (ThrottleStop.sys) has a confirmed vulnerability that would allow potential malware to abuse it in order to escalate privileges and get access to the kernel. I currently have a Strict Kernel-Mode Policy deployed, and ThrottleStop.sys is among the whitelisted drivers. I understand that the best solution in terms of security would simply be removing the driver from the whitelist, but in case I still wanted to use ThrottleStop, would there be some other solutions to somehow limit the risks? For example, is it possible to modify the policy so that only ThrottleStop.exe would be able to access/use the driver and no other program at all? Are there other measures I could apply?

[HotCakeX]

Hi, not with App Control for Business. What you're asking for can be done but only for user-mode programs and executables. You could use other measures to control your attack surface and limit the potential of that driver being abused by external sources, by using the Harden System Security app.

P.S I see Throttle Stop is a program for monitoring CPU temp, power etc., some of which the apps in this repo provide, some aren't available which i could add if needed. There must be other programs that could offer the same features more or less and not use a vulnerable driver. If using Intel CPU, i think Intel has a software for that job too.

[HotCakeX]

Well you can be sure that all of those kernel-mode drivers were indeed loaded and used by the OS at some point since you deployed the audit policy and rebooted, but it's hard to tell which one would cause boot failure if not allowed to run.

The policy you have is safe to use, if you'd like to make it smaller i'd suggest removing the drivers themselves first (via their installer programs, not device manager etc.) and then regenerating the policy, that way you can't have boot failure, because when you clean install the OS for the first time, it works fine out of the box without those 3rd party drivers (unless they are really critical like some SSD drivers, VMD etc.). Those critical drivers usually don't have a software and you'd have to install them during OS installation screens, so you would know what they are and they most likely only live in device manager.

So basically if you'd like to reduce your 3rd party drivers footprint I suggest going to the Settings -> Apps -> Installed Apps and uninstall the software for drivers you installed, that's the safest way imo. Blocking them via App Control policy would be dangerous if you're unsure.

If you still go ahead and block critical driver via an App Control policy and get yourself into a boot failure situation, you would have to access WinRE environment, open notepad or task manager to use their file browser feature, or use command line to navigate here C:\Windows\System32\CodeIntegrity\CIPolicies\Active, then remove the kernel mode policy. The file names in there are just GUIDs so you would have to sort that folder by date and delete the policy with the newest date (if you don't know the exact policy ID). That's the location of unsigned policies. Definitely don't deploy signed policies without testing them unsigned first because then you'd have to do a couple more steps to remove them in case of a boot failure, such as fully disabling Secure Boot in the UEFI/BIOS and revoke your BitLocker keys (if any) etc. https://github.com/HotCakeX/Harden-Windows-Security/wiki/The-Strength-of-Signed-App-Control-Policies

[cldy2nyt]

I've noticed that most of the drivers in the whitelist are from either Intel or Nvidia.

Regarding the removal of unsigned policies, can you confirm that you would still need to provide bitlocker pin before being able to remove them? Otherwise a person having physical access could remove them without issues

[HotCakeX]

BitLocker startup pin is always required when BitLocker is properly configured, you can't access the encrypted disks without it.

If you set up BitLocker via the app then you'll have a 48-character recovery code too that you can use to unlock your disk if you ever forget the startup pin.

[cldy2nyt]

Perfect thank you.
Regarding throttlestop, I haven't found any program that allows to set and modify PL1 and PL2 CPU values after boot. What were you referring to when you said "You could use other measures to control your attack surface and limit the potential of that driver being abused by external sources, by using the Harden System Security app", did you have anything specific in mind?

[HotCakeX]

Yes, applying the ASR rules, Microsoft security baselines and pretty much as many of the security measures in the app as possible will be helpful for you to stay more secure.