Make HWiNFO runnable under a limited account, please!

[inbetweener]

Years and years, upon searching, I see users have been trying to run HWiNFO under a Limited/user account, and it still seems to remain undoable. I've tried every trick suggested and every I could rack my brain to think of: using schtasks in a particular way, using runas with the /env flag, adjusting every setting there is within the scheduled task that allows it to auto-run under Administrator.

It seems to be deliberately coded to resist being run in any other account. So what, the developer expects a user to break his system security by running his computer as an Administrator in the day-to-day? 94% of security threats are eliminated by running your computer in a standard account. That's why back in the day there was no such thing as virus scanners for Linux, because they didn't need them. No intelligent Linux user was running his computer under root and therefore any virus exposure meant nothing. 94% increased security vs... whatever obscure security risks the developer seems to allude to? Funny, Corsair's iCUE can run perfectly as both Administrator and user, and provide much of the same data.

My interest is in using Rainmeter + HWiNFO to create a little in-case system monitor LCD. How about you fix your software for once so users like me can use it, instead of writing your package for those who run their computers utterly irresponsibly and ignorantly (as an admin). Again, users constantly trying as this forum shows, and the developer always giving dodgy non-answers. Maybe he just doesn't have the skill to make it run properly?

 

[inbetweener]

Hell I've 'tricked' 'FanControl' (BEAUTIFUL software btw) into running almost like a service via Task Scheduler, as admin and user. It runs non-interactively, but it controls my fans as I've designed the curves under the administrator account. Again this makes me think this limitation is deliberate and obstinate on the developer's behalf. Hell, every firewall program I've used runs in both admin and user, and allows you to make changes to rules as both.... but it's too risky to allow a monitoring program to run in a user environment? Nah something not adding up here.

 

[inbetweener]

AND ANOTHER THING. (I'm fairly passionate about this, and my computer security in general... but particularly because I just invested in a 6 inch little LCD in plans of this HWiNFO+Rainmeter setup (and I don't think Rainmeter takes input from other apps, or.. not as much info), and my plans are dashed now? Listen, if a user is willing to use tricks to make an administrative program run in a user environment, he's taking his security into his own hands. But this developer is like "no, your computer security is under my control"; "you only get the kid gloves, kid".

 

[Martin]

Initially I didn't want to respond because your posts are full of stupid conclusions, accusations and indicate lack of deeper understanding of one thing - SECURITY.
But instead of banning/deleting your posts for breaking forum rules, I will take the time to respond although I don't expect you to read it entirely because you have made your conclusions and I might be wasting my time...

First - HWiNFO requires a kernel driver to access hardware and provide all the important information that are possible only thanks to kernel access. This is same for all other hardware monitoring tools.
Several years ago, HWiNFO was written so, that only initially (during install) it was required to run under Admin to install the driver. Then, subsequent runs allowed running HWiNFO under a user account and talking to the driver. You'd say this is great and you'd feel safe because you don't run under Admin. But guess what:

CVE-2018-8061 : HWiNFO AMD64 Kernel driver version 8.98 and lower allows an unprivileged user to send IOCTL 0x85FE2608 to the device dri

CVE-2018-8061 : HWiNFO AMD64 Kernel driver version 8.98 and lower allows an unprivileged user to send IOCTL 0x85FE2608 to the device driver with the HWiNFO32 symbolic device name, resulting in direct physical memory read or write.

www.cvedetails.com

I won't go into further details why that is a problem but if care about security, you should read some articles about this kind vulnerability and why is it a problem.

Also be aware that Microsoft takes security quite serious and if they become aware of a vulnerability in a kernel driver, they will block it. That's why there are driver block lists in later Windows versions:

Microsoft recommended driver block rules - Windows Security

View a list of recommended block rules to block vulnerable third-party drivers discovered by Microsoft and the security research community.

learn.microsoft.com

You might notice that the old HWiNFO driver (among many others including renowned companies) are on that list. Pay special attention to the WinRing0 driver.

So in all your conclusions you were right in one thing - yes, this limitation is deliberate, intentional and needed. And exactly for one purpose - SECURITY.

It's great that you found a BEAUTIFUL software like FanControl, but let me tell you one thing. Did you know that FanControl includes the LibreHardwareMonitor (LHM) ? And did you know that LHM has its own kernel driver? Now guess which one............. https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/tree/master/WinRing0
Do you still feel safe? Let me just say that WinRing0 is one of the most vulnerable drivers because it doesn't perform any security checks, allows unprivileged applications to use it (being open source is an advantage for attackers as they know the interface) and it offers arbitrary access to privileged resources including writing to MSRs or entire physical memory! Do you still feel safe?
Does LHM know about a problem with their driver? Of course they do. Do they have a secure solution? Well you can read yourself:

WinRing0 get's blocked by Avast/AVs · Issue #984 · LibreHardwareMonitor/LibreHardwareMonitor

There's a CVE for WinRing0 https://www.cvedetails.com/cve/CVE-2020-14979/ See also https://posts.specterops.io/cve-2020-14979-local-privilege-escalation-in-evga-precisionx1-cf63c6b95896 @PhyxionNL ...

github.com

They didn't fix this problem because it would require substantial effort - financial (EV certificate) and in development (a complete different approach to remove arbitrary access). This is BTW the difference between fully free software which usually lacks the resources to perform such tasks. HWiNFO being a freemium solution allows to invests into such effort.

You might be wondering why the LHM driver isn't blocked by Microsoft. Even though it's the same WinRing0 driver that is already blocked, the MS block list is based also on file name and LHM has just renamed it. Does MS know about this? Of course they do and they are watching it closely and tightening... One of the reasons for not blocking this driver is because there are no known exploits/attacks based on this (YET). I know that because I had several discussions with the security team at MS and I have to say that some of their decisions seem too weak to me... But IMHO it's just a matter of time.... If I'd want to, I could write an exploit for LHM in a couple of minutes and it would work without Admin rights.
And BTW, LHM isn't the only software utilizing the WinRing0 driver. There are others like OpenRGB, etc...

I could also mention other issues with LHM like this one:

Improper accessing the Nuvoton eSIO causes problems with other monitoring software · Issue #1243 · LibreHardwareMonitor/LibreHardwareMonitor

Nct677X doesn't properly access internal registers of the eSIO (ReadByte, WriteByte) which results in blocking other software. The eSIO features a "sort of mutex" to handle parallel access, which i...

github.com

I have reported this, provided information how to fix it and there's a fix for it pending for several months only because someone cares more about coding style and blanks, rather than stability:

Nct677x esio mutex by sebastian-dev · Pull Request #1254 · LibreHardwareMonitor/LibreHardwareMonitor

Fix the access with multiple devices. Issue: #1243 Improper accessing the Nuvoton eSIO causes problems with other monitoring software

github.com

Then users unaware of this (also using FanControl) blame HWiNFO for issues that are in fact somewhere else.....

So next time before trashing someone, please have a deeper read on the topic. And because you bought an LCD doesn't mean the entire world has to bend according to your will.

 

[inbetweener]

So it's exactly as I supposed it was, and I 'trashed' you for good reason, but please don't take it personally. I want to use your software. But also, I've seen you 'help' users on the forum over the years, as they struggle and struggle, wasting hours trying to get HWiNFO to work with auto-start in a user account, and never once did I see you admit outright "yeah I've completely disabled that, deliberately" - usually you faux-help them with things like "this might work". Deserves some spurn doesn't it?

Here's exactly what it was: "I don't care that you're willing to take your computer's own security into your hands and run HWiNFO in an unsupported way, I'm going to deny you to do so because I need to keep you safe." Same mindset as Microsoft... and anyone who understands if you understand SECURITY or just basic logic, if you're relying on Microsoft for your security you're already lost.

Initially I didn't want to respond because your posts are full of stupid conclusions, accusations and indicate lack of deeper understanding of one thing - SECURITY.

Like the security of encouraging your users to incur 94% more general threat to their account, by running it as an administrator? To alleviate your.. obscure .004% risk threats... well, more, to alleviate your conscience I suppose for what happened with your product? .004% lets say these little vulnerabilities you list represent vs 94...... hmmmm.... who doesn't understand security? The game developers of Icarus actually put a warning in their game if you run it within an admin account saying "this is an administrator account: don't run the game like this". Now that's understanding security.

Do you still feel safe? Let me just say that WinRing0 is one of the most vulnerable drivers because it doesn't perform any security checks, allows unprivileged applications to use it (being open source is an advantage for attackers as they know the interface) and it offers arbitrary access to privileged resources including writing to MSRs or entire physical memory! Do you still feel safe?

Yes, I do feel safe. Because I know how to operate my computer. Because these minor exploits you speak of almost never actually surface in the wild. At least, in my decades long experience, I've never experienced a single virus because I don't a) rely on Microsoft or b) rely on any individual software vendor for my security.

And another thing you didn't address was Corsair's iCUE: used by probably 10x the people that FanControl and HWiNFO is combined, and it offers full system temps and fan numbers as a user. So is iCUE putting their users security at such high risk that you won't tolerate, or maybe they just wrote their code differently?

You know how many little security threats you could pull up just like that and worse, for every single program out there. You have any memory of Windows 98 and how they had port 137 open or whatever it was for years? And gee, here's the thing, these are only the known exploits. An exploit only gets attention from Microsoft, for example, after it's discovered, which can be months to years after its use. There is no operating in a bubble online, ever, so I, like I imagine many HWiNFO users (and wannabe) users, would rather just make our own decisions about what's secure enough for us.

 

[Martin]

I'm not going to dissect iCUE but I'm pretty sure it comes with multiple services and kernel driver(s) that get installed. Further responding to this would increase the trolling %, so I will refrain from that.
Good luck with your security concept!

 

[inbetweener]

'Trolling'. Nice cope word.

So... you use your own software right..? You mean to tell me.. you run it in an admin account? The MOST irresponsible thing you can do when it comes to your computer's security? Or do you just run it to monitor a quick few things and go back to your limited account or what. And you want your other users to do that? Just run it to check on things quickly... or do you expect that they're operating day-to-day, in an administrator account? For someone like that to comment on security (you definitely understand the specifics and technicalities better than I do) but you definitely have no grasp of the basics.

 

[inbetweener]

You mean everyone here, having issues with the program are running as administrator? That is a disaster of computer security exponentially greater than the one you think you're fixing:

A recent study from security vendor Avecto found that 94% of critical vulnerabilities announced by Microsoft could be mitigated by simply removing administrative rights.

^ link seems to be old and dead

Here's just a "bleepingcomputer" article: Removing User Admin Rights Mitigates 94% of All Critical Microsoft Vulnerabilities

But, I shouldn't need to prove it with articles or studies. It's common sense, and has been common practice for anyone capable of running anything more sophisticated than Windows since the 90s.

 

[Martin]

OK, just for the record - the original thread title was "What is wrong with this developer?". But I appreciate that you changed the title at least.

Now to summarize this - tools like HWiNFO need Admin rights as they need to access hardware directly. Without this, the provided results would be about 10% of the total capability. So no matter how the main application runs, they will always need to install something providing privileged access.

You live in a big illusion if you think that an application running under ordinary user but installing a kernel mode driver (and/or a service under a SYSTEM account) gives you higher security than an application running constantly as Admin. On the contrary - if a system component (e.g. kernel driver) allows to be directly accessed from a non-Admin application, it does in fact open a potential backdoor. Not mentioning applications shipped with drivers allowing arbitrary hardware access.
It's much easier and more powerful to exploit such vulnerable driver than an application running as Admin. With such an "all-welcome" driver you can do almost anything - steal secrets from other processes, overwrite kernel tables, read or write protected hardware registers.. And all that can be done without the need to change anything - just use the publicly exposed interface of a running driver even without Admin rights. To hijack a digitally signed app you first need to find some weak spot and then "inject" something into the running process. Even that would give you a limited room to play. If I'd be an attacker, I'd certainly chose the vulnerable driver.

There's no 100% security guarantee and one always needs to make compromises or put trust into something. We're doing this several times every day. Of course, you can completely remove Admin access - you will get a somewhat more secure system but with a very different (reduced) feature set. Yet, it won't prevent you from clicking a scamming link in e-mail redirecting to somewhere...

And BTW, did you know that CPUs, chipsets, GPUs and other components like IME run their own secret firmwares into which you have 0 visibility? And these run with much higher privileges... How much do you trust them? What if there's something hidden, what chances do you have to avoid that? You can only trust the vendors that they didn't include any nasty backdoors there, or at least not activate them in your case. When you type a message, or write an e-mail in your favorite app, how do you know that it stays only where you think? Don't answer, please..

 

[inbetweener]

And BTW, did you know that CPUs, chipsets, GPUs and other components like IME run their own secret firmwares into which you have 0 visibility? And these run with much higher privileges... How much do you trust them? What if there's something hidden, what chances do you have to avoid that? When you type a message, or write an e-mail in your favorite app, how do you know that it stays only where you think? Don't answer, please..

What are you even talking about? I'm not the one taking the "we're going to create a perfectly secure environment" tact. Wouldn't that more be what you're doing? "You can't run my software unless it's 100% secure for you to do so."

You live in a big illusion if you think that an application running under ordinary user but installing a kernel mode driver (and/or a service under a SYSTEM account) gives you higher security than an application running constantly as Admin. On the contrary - if a system component (e.g. kernel driver) allows to be directly accessed from a non-Admin application, it does in fact open a potential backdoor. Not mentioning applications shipped with drivers allowing arbitrary hardware access.

YOU'RE TALKING ABOUT ONE APP. WITH ONE VULNERABILITY. And how is a person even picking up this ringworm.0 or whatever it was you mentioned? Bad security practices? Lemme ask you, those bad security practices... do you think they pose the user more of a threat to himself under a limited account, or an administrator account? Do you think.... everything you do, is not safer in a limited account? Nothing can make system changes. No typical virus can propagate. Exploits and things will fail for nearly all apps, and that's particularly important when you're online. You want to be online, in admin, playing games and such with who knows what kind of exploit exists to give the attacker access... to your administrator account, since you were so silly to use it. You have no argument about one threat being bigger than the other here.

And what I'm asking for isn't official support for a (as it may be) vulnerable HWiNFO. I'm simply asking that you remove the code that, as you've admitted, deliberately prevents any kind of trick from being used to allow it to run outside of admin, out of respect for your many users, I'm sure, who want to take the risk and use it to do what they want. You certainly wouldn't be liable for any damages they incur by usage you advise against. Who are the people who use your software, largely? Enthusiasts. Enthusiasts, many many of whom, take unnecessary risks with their PC (via overclocking, modding, etc). You don't think those people would appreciate the ability to use your software "at their own risk"? Or would you be the guy who locked all CPUs so that users couldn't do anything unsafe with them?

(Or at least a limited version of the program which just provides temp/fan for basically all the devices, CPU/GPU/SSD is what I'm after.)

 

[Martin]

Again - removing THAT code would mean a drastically reduced feature set. None of the sensor features you're asking for would be possible to read. Feature-wise it would be something similar to Task Manager, maybe even less.

 

[Dalai]

@inbetweener
You do know that you can run HWiNFO - or any other software, for that matter - under a different user account which has administrator privileges, while still running ordinary programs like a browser, games or whatever in a limited account, right?

All of my systems have a strict user separation, where the user is NOT member of the administrators group, and still I've been running HWiNFO for many years. How do I do that? Well, via the "Run As Administrator" feature in Windows, basically. It's a little more fancy because I'm too lazy to type in the admin password every time, so I use a program called RunAs Professional. I've been doing the same for other programs that require administrator rights such as SpeedFan, MotherBoard Monitor (though that was many years ago) and tools like Process Monitor, Process Hacker and so on.

 

[inbetweener]

@inbetweener
You do know that you can run HWiNFO - or any other software, for that matter - under a different user account which has administrator privileges, while still running ordinary programs like a browser, games or whatever in a limited account, right?

All of my systems have a strict user separation, where the user is NOT member of the administrators group, and still I've been running HWiNFO for many years. How do I do that? Well, via the "Run As Administrator" feature in Windows, basically. It's a little more fancy because I'm too lazy to type in the admin password every time, so I use a program called RunAs Professional. I've been doing the same for other programs that require administrator rights such as SpeedFan, MotherBoard Monitor (though that was many years ago) and tools like Process Monitor, Process Hacker and so on.

That would require typing your administrator password, into a user account. Something I never do, because I consider it again, irresponsibly insecure. What if you had a keylogger or a virus.. limited to your user space by your limited account, just waiting to capture that? Nope, will never EVER type an administrator password into a user account. There is zero cross-contamination between my user space and admin space, and almost zero potential for any.

RunAs Professional, perhaps I'll look up: if it stores the password in a way that's on par with how Windows stores your passwords, that might be viable.

Surprised more people haven't taken my side though. You know what I realized? Because I researched the years of people attempting to get HWiNFO to work with 'tricks', like the one which allows me to run FanControl... is that sometimes people have found ways to make it work, but now they don't work. I'm guessing the developer went in and deliberately disabled that workaround. Again, that's not a respect for your users, that's adherence to an ideology which you force upon your users. And over faulty logic too. Do you have any idea how many known and unknown exploits every program everyone is running daily probably have? lol.

 

[inbetweener]

I bet if you did a poll, to see who would be in favour of the dev removing the code preventing all work-arounds (which I imagine is just a fairly uncomplicated block(s) of code which say "if not fully admin in admin environment, fuck off" vs who wants to be kept safe.. (while being forced to do much riskier things like run their computer in the administrator account, etc but I digress)... the support would overwhelmingly be for the former. Actually, if I'm being honest, I think it'd be pretty evenly split, but idk, what self-respecting enthusiast wants to be prevented from doing anything on his machine?

 

[Martin]

Warning! Calm down

 

[Dalai]

RunAsSpc is a program similar to RunAs Professional, and IIRC the former is free while the latter is shareware.

It's also possible to run HWiNFO via Scheduled Tasks. Once a task is created it can be run from a user account, e.g. via schtasks.exe. And btw, HWiNFO uses this option to automatically run at startup.

In other words, there are several ways to use HWiNFO without being a member of the administrators group or having to type a password. You just need to know what's available in Windows (or maybe in regards to 3rd-party software). And no, "removing code requiring admin rights" is just nonsense, as Martin already explained.

PS: I'm one of the first people to complain if a program requires administrator rights, and I've seen a lot of them over the years, including cases where it was complete and utter BS to require these rights. But in this case here it's fully justified.