WinRing0 is being flagged as malware by Windows Defender

[Sparronator9999]

WinRing0 (note: this link is a mirror of the original source) is a kernel driver used by many system monitoring/control apps, including YAMDCC. I have recently come across reports of WinRing0 being flagged as malware (specifically HackTool:Win32/WinRing0):

• https://www.xda-developers.com/windows-flagging-monitoring-malware-reason/
• https://www.makeuseof.com/windows-defender-alerts-monitoring-software-winring0/
• https://www.theverge.com/report/629259/winring0-windows-defender-fan-control-pc-monitoring-alert-quarantine
• https://github.com/Rеm0o/FanControl.Releases/discussions/3017

These malware reports are not coming out of the blue, as the driver has a vulnerability tracked by CVE-2020-14979. This was patched by this project, but (as of writing) was never built and signed by the developers (see the next two sections for why).

What's this about a WinRing0 vulnerability?

Basically WinRing0 sets itself up in such a way that any application (including unprivileged processes, i.e. those not running as Admin/with UAC privileges) can use all the functions of WinRing0, including reading and writing arbitrary MSRs, memory locations, and I/O ports (the last one is the only functionality YAMDCC uses). This allows for local privilege escalation of an unprivileged process.

See the NVD's website for more info.

YAMDCC works around this vulnerability by setting an ACL on the object that WinRing0 provides on installation to restrict access to the SYSTEM account and system administrators (see lines 157-166 of this source file).

Why can't you build and sign the driver yourself?

Building the driver is no problem, but getting it signed is costly (due to the EV certificate requirement). See Microsoft's kernel-mode code signing requirements, and more generally their driver code signing requirements for more information.

What will YAMDCC do about this going forward?

There are a few options available for the future of YAMDCC:

• Keep using the vulnerable (but signed) driver, and ask users to whitelist the YAMDCC installation folder. This isn't ideal, but means we wouldn't have to complicate the setup process with enabling test-signing. It would also require trusting the YAMDCC developers (currently just me) to not give you malware (but this project is open-source, so you can hopefully see no shady business going on).
• Build and sign the patched WinRing0 with a test-signing certificate. This isn't ideal, as test-signed code isn't meant to be used in production, and requires disabling secure boot and tinkering with Windows' boot loader configuration.
• Make our own EC access driver. I was originally thinking of doing this when I originally heard about the WinRing0 vulnerability, as it reduces the attack surface compared to WinRing0 by only allowing EC reads and writes, and would also use IoCreateDeviceSecure to patch the issue of any application (including unprivileged apps) from being able to arbitrarily write to the EC. This has the same issues with test-signing as just test-signing and including the patched WinRing0 library.

Leave your thoughts in this discussion thread.

[porkmanager]

WinRing0 has been included into dr. Web bases now. Im not using any AV software but sometimes run drweb scaner, never seen this before.