Bug: BitDefender reporting Hass.Agent.sys as Potentially unwanted app

[drax-uk]

Please make sure that the issue you're planning to report is not already registered :)

---

Describe the bug When I try to run Hass.Agent I get Bitdefender the below notice

Screenshots

Misc info (please complete the following information):

• Windows version: Windows 11 23H2
• Windows' UI language: English
• HASS.Agent version: 2.0.1

Please check what's applicable (multiple answers possible):

• [x] Installed via installer
• [ ] Installed manually
• [x] Problem occurs in HASS.Agent
• [ ] Problem occurs in Satellite Service

[amadeo-alex]

Can you provide more details from the AV? Some of AVs have false report on the libre hardware monitor that HASS.Agent uses - https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/issues/675

[drax-uk]

Unfortunately, I could not find anything in the Bitdefender logs about this. the message just pops up and when it finishes scanning then it disappears.

the only thing I found is this in Bitdefender central

[amadeo-alex]

My bet would still be on LibreHardwareMonitor being falsely flagged but can't be certain without additional information/logs from the reporting AV.

[DarkAutumn]

@amadeo-alex I've been digging through this for the last day, and this is not a false positive. This is an exploitable security issue.

HASS.Agent.sys is just a renamed/resigned and possibly modified version of WinRing0.sys. This product has a well-known CVE that hasn't been addressed. You can see more here: https://github.com/GermanAizek/WinRing0/issues/9

Which has an example of it being exploited in the wild for years here: https://www.safebreach.com/blog/hp-touchpoint-analytics-dll-search-order-hijacking-potential-abuses-cve-2019-6333/

What's worse, the version of this file that is included in this version of LibreHardwareMonitor does the following things:

1. Allows the caller to read/write the MSR, allowing the user of the driver to disable memory protections and CPU security features. It allows you to switch to ring 0, and a wide variety ways to create persistent backdoors to the system.
2. Read/Write raw memory. This bypasses all access controls and privileges. This is a very simple way to elevate privilege...it's not even hard.
3. When it sees IOCTL_OLS_HALT it hits the HALT instruction itself. It just hangs the thread that called it forever... I'm not sure why that'd be desirable. Interestingly, this is not what the current source code for WinRing0.sys does. Maybe this was changed/fixed in a later version (but not the one included with LibreHardwareMonitor)
4. Allows modification of PCI configurations (not just reading them).
5. Does not use IoCreateDeviceSecure.
6. Probably some other things I haven't had a chance to dig through.

Then, this driver creates a symlink in usermode to \\DosDevices\WinRing0_1_2_0. This allows user mode code to raw access this functionality (probably that's how LibreHardwareMonitor is implemented) but never calls SeSinglePrivilegeCheck or related functions (it's literally not even in its imports).

This means any user mode application can walk up to that symlink and overwrite some memory to elevate privilege, turn off CPU security features, and a wide variety of other crazy stuff.

This is now a 5 year old vulnerability that is very well known and already exploited. I'd strongly suggest removing the dependency on LibreHardwareMonitor until something is done about that (even if that pulls back features). As it stands today, any computer that you install HASS.Agent onto will be exploitable by all kinds of nastiness in the same way the HP link above describes.

[DarkAutumn]

It looks like here is the updated issue they are talking about this over on LibreHardwareMonitor: https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/issues/984

Hopefully they get it sorted out, as the current WinRing0 they have in their project is rightly being flagged by antivirus/anticheat software. :(

[amadeo-alex]

@DarkAutumn thank you very much for the time and research!

I'll be fully back next week and intend to dig into this (first priority after 2.1.0 is out). In the meantime I did some digging (also found out that thread) but it looks grim to be honest - the bullshittery one needs to go through to have a signed driver is a lot both in monetary and effort department, and this is what would be required to have it fully fixed and working by default on all devices if I understood correctly. I'm already doing some research on alternatives but none are found, we'll need to remove this dependency.

Users will be of course free to install LibreHardwareMonitor as standalone app and use WMI but that is going to be their own choice - we cannot knowingly distribute software with a vuln...

[DarkAutumn]

I'm already doing some research on alternatives but none are found, we'll need to remove this dependency. Users will be of course free to install LibreHardwareMonitor as standalone app and use WMI but that is going to be their own choice - we cannot knowingly distribute software with a vuln...

That sounds like a reasonable approach!

the bullshittery one needs to go through to have a signed driver is a lot both in monetary and effort department, and this is what would be required to have it fully fixed and working by default on all devices if I understood correctly.

Yeah, it's a tough situation. The Windows ecosystem requires a driver to access deep hardware information (shallow stuff is easy to get but that's not what LibreHardwareMonitor is after). Writing Windows drivers safely and securely in a way that doesn't cause bluescreens is actually very tricky. (So is writing a Linux kernel module for that matter. :) )

Getting Windows Drivers signed does cost money, because Microsoft actually tests and validates the driver, which costs the company money. That makes sense, IMO. Linux doesn't charge for Kernel model testing, but you also can't (reasonably) get a Linux kernel module into the kernel itself...which is kinda like having signed drivers. It's a very different trust model, but it's analogous. The Linux path may be cheaper, but it doesn't make it any safer or easier to get right...it's just different.

In this issue, the fundamental problem here is that LibreHardwareMonitor found an interesting tool (WinRing0.sys) and build a library on top of it, but WinRing0 isn't secure and well-made. It looks like LHM developers are unable/unwilling to build their own driver (which makes sense, it's difficult and expensive). This leaves LHM in a bad place, as they are depending on something that makes their entire library work...but that thing is fundamentally insecure.

In any case, I'm just ranting. Kernel development is hard, folks have to expect the costs. I think hass-agent will be fine without needing to worry about it if you remove the dependency.