Windows Defender Now Flags WinRing0 Driver as Security Threat, Breaking Multiple PC Monitoring Tools (theverge.com)
- Reference: 0176714083
- News link: https://it.slashdot.org/story/25/03/14/1351225/windows-defender-now-flags-winring0-driver-as-security-threat-breaking-multiple-pc-monitoring-tools
- Source link: https://www.theverge.com/report/629259/winring0-windows-defender-fan-control-pc-monitoring-alert-quarantine
WinRing0 gained popularity among developers because it's one of only two freely available Windows drivers capable of accessing the SMBus registers needed for hardware monitoring functions. The affected applications include Fan Control, OpenRGB, MSI Afterburner, LibreHardwareMonitor, and multiple others that rely on this driver to communicate with system hardware.
[1] https://www.theverge.com/report/629259/winring0-windows-defender-fan-control-pc-monitoring-alert-quarantine
Re: (Score:2)
> And yet our mission critical software still relies on a backwards compatible design from the 1980s designed for an 80386 with 16MB of RAM.
Wait Linux didn't come out until the 90s, What are you talking about
Seems like MS should write a driver+dll combo (Score:2)
With such functionality, and market it along the lines of "DirectRGB" "DirectFanControl" "DirectSMBus" or somesuch.
That way, all third party HW monitoring sw would be covered by an unified AND MS-Vetted framework, and, for a change, Win11-25H2 would have and ACTUALLY USEFULL feature.
Should never have been allowed (Score:3)
I used this driver circa 2008 when doing some driver development, but would never have created a product that included shipping it. Kernel access should be specific, not generic. A fan-speed monitor needs to read/write one specific IO port configured at install time, installing a kernel driver that does not provide parameter checking as part of a software release because it saves you from having to get a driver signed is a really bad idea.
The list of people complaining about this breaking their tool is the list of people who either did not understand implications of bundling this or did not care. Either way these are not the people you want delivering kernel mode drivers to your system.
Don't complain (Score:2)
Write a proper driver rather than relying on this type of nonsense.
Re: (Score:2)
I'd say the driver is necessary, bc you can't access hardware without this kind of driver. This kind of monitoring software needs access to a bunch of low-level details there's no other way to get access to.
However... There needs to be a mechanism restricting it so that Malware cannot piggyback on the same mechanism, and so the programs that legitimately need access have to be assigned special privileges and cannot have malicious code injected into those programs.
Re: (Score:2)
No, A driver is necessary, but THE driver is not necessary.
A device driver exposes hardware FUNCTIONALITY, not hardware itself. That's the entire point of a driver and an OS the provides protection of hardware from applications.
"... restricting it so that Malware cannot piggyback on the same mechanism..."
Yes, that's getting the mechanism right, exactly what a driver does. A driver that exposes hardware to be manipulated by an application is an exploit, a driver cannot tell the difference between malware a
Re: (Score:3)
A device driver exposes hardware FUNCTIONALITY, not hardware itself.
That's not what these applications require. These applications require Generic access to the dedicated system management bus (SMBus)
from program code running inside Userland; not the kernel: so that they can submit and receive the PCRs on the bus in order to find all components and Poll all the registers for sensor values.
You cannot use traditional drivers for this. You don't even know what the exact hardware will be ahead of time.
Your G
Re: (Score:2)
> A device driver exposes hardware FUNCTIONALITY, not hardware itself.
You mean like the functionality the SMBus communication chip provides? That functionality?
Re: (Score:2)
TFA has some interesting detail. Apparently there was a known vulnerability in the driver, and it's been patched. The problem is that it costs real money to get Microsoft to review it and issue a certificate so it can be installed.
It would be better if manufacturers used USB instead of SMBUS, or a bridge chip.
Re: (Score:3)
Problem is that it costs real money to get Microsoft to review it and issue a certificate so it can be installed.
Sounds like it's about time for some users of these 3rd party programs to pony up some money then, right?
It costs real money, but I don't believe we should be persuadable that Logitech, Razer, MSI, and Panorama don't have enough real money to cover a $1000 Driver signing cert for at least 1 Dev. I mean.. Panorama literally in the business of selling System monitoring to large enter
Re: (Score:2)
It's the organizing part that is the difficult bit. You need someone to take charge, collect funds, and then work with Microsoft to get it certified. If it fails certification they need to fix the issues.
Re: (Score:2)
> The problem is that it costs real money to get Microsoft to review it and issue a certificate so it can be installed.
It would be better if M$ wasn't a classist and corrupt criminal organization and these problems were handled in a professional and responsible manner. Economic ransom is exactly what happens in a corrupt economy.
Re: (Score:1)
Geez grow up.