The Microsoft blog might stop short of calling it malware, but I think we don't need the faux politeness here. The fact that their malware also contained a privilege escalation (the "vulnerability") is merely icing on the cake.
Source: I've written kernel drivers and exploits.
As the full saying goes.
Never attribute to malice what can be explained by stupidity...but don’t rule out malice.
All code is security code.
Debian disagrees. They are wrong to do so.
Inspecting MateBookService.exe!main revealed a “startup mode” that revived the service if it’s stopped – some sort of watchdog mechanism meant to keep the Huawei PC Manager main service running.
I agree that it’s hard to prove malice, but why should any PC management software go out of their way to ensure that it never gets shut down?
Like this stuff is usually designed by EEs and they love their watchdogs at all levels. Having a watchdog is very standard for this stuff.
I’m no expert on device drivers but to my knowledge, Windows already allows you to manage devices and install drivers through Device Managers.
Then if drivers are already installed for the various devices and hardware components, what exactly is the hardware management service managing on top of the individual drivers?
I am asking this as the only plausible reason to be doing this (at least for me) is if Windows isn’t providing enough tools for device management that needs coordination between the hardware components on the machine, so I would appreciate someone with more knowledge to shed some light on the subject.
> why should any PC management software go out of their way to ensure that it never gets shut down?
The Windows 10 kernel itself goes out of its way to make sure the Windows update service isn't permanently shut down.
Maybe we have different expectations of what a driver is. Take a look for yourself, even the updated PC Manager Software on their website still has the driver with the goofy shellcode in its installer (no idea if it's just not loaded now):
> malicious - adj. - having or showing a desire to cause harm to someone
I'ts goofy, and wouldn't pass a design review that I was a part of, but it isn't "showing a desire to cause harm". It just looks like a rushed design.
> about a driver whose pure function (this thing literally has no other value or purpose)
I see nothing about how this driver doesn't have any other functions.
> is maintaining an invincible NT_AUTHORITY process of their pre-installed management software
Because you want the hardware management process to be resurrected if it fails. They're not gaining anything from an attack perspective by deferring to user mode, the process isn't hidden, and they're already running as a kernel driver so they have full control of the system as it is. In Raymond Chen's parlance, they're already on the other side of the airtight hatch.
> Maybe we have different expectations of what a driver is.
I mean, Minix ascribes it's uptime and reliability to a resurrection server. Is this a much crappier design? Yes. Is it such a bad design that it's malicious? No, that's absurd.
> Maybe we have different expectations of what a driver is.
I expect drivers to defer everything they can to user mode so they don't crash the kernel. That's one of the reasons why APCs exist in the first place.
> Take a look for yourself, even the updated PC Manager Software on their website still has the driver with the goofy shellcode in its installer (no idea if it's just not loaded now):
Oh no, they didn't take that out of their package, but even Microsoft says that they fixed the vulnerability, and quicker than responsible disclosure asks for.
Obviously, you didn't look at it.
This is the irony of it all. There is nothing simple about writing a device driver to do what literally three lines of code in userland registering a service could have achieved. It is the furthest thing from a rushed design you could possibly do; it is taking the wrong turn 10 times and incurring exponential costs each time. That is why it's called a backdoor or malicious; it demonstrates unique niche knowledge in things that are the furthest imaginable distance from the shitty .NET amalgamation that their actual PC manager software is.
Particularly given that they describe how there's multiple ioctls.
And I can tell you from experience that relying on the service manager for a full watchdog solution is fraught with peril. It'll catch hard crashes, but not for instance dead locks.
Plausible deniability. If you were to implement a backdoor for a company, would you write "professionally done" all over it?
Given the circumstances, one might wish to err on the side of caution.
This doesn't mean the actual flaw was malicious, but being actively exploited, it seems intent doesn't really matter.
> While monitoring alerts related to kernel-mode attacks, one alert drew our attention:
>The alert process tree showed an abnormal memory allocation and execution in the context of services.exe by a kernel code. Investigating further, we found that an identical alert was fired on another machine around the same time.
This shows code injection taking place, via the exploited code. You are right that they don't mention what code was injected (probably they don't know)
Their scanner doesn't show any exploitation happening, and they don't say that it does.
You are right that they don't seem to know what code was being executed. Just that some code (be it real code or random garbage) was injected and executed.
They know the code it's running for the most part, it's the CreatProcessW stuff they talk about.
That's what you need to achieve plausible deniability. You'll need to make it look innocent.
(I also write Windows kernel mode drivers.)
Either Huawei's driver developers are both incompetent and stupid or they're injecting malicious backdoors.
Please, continue.
But FWIW, it's a pretty common thing for shitty drivers. Here's one example: https://forum.xda-developers.com/showthread.php?t=2057818
This is simply news because it's Huawei and many want them to be guilty of backdooring US entities. Perhaps they are, but no more many other "respected" US companies.
Edit: I'm not sure if it's considered appropriate to ask for credentials on HN. There's one way to find out :)
The only reasonable usage of such a situation is for the magician him/herself, to study his/her own performance. And even then, it is not usually done that way.
And while there's better ways to handle it, and it wouldn't pass a design review of mine, it's pretty common to make a driver specific /dev/mem equivalent. For isntance https://forum.xda-developers.com/showthread.php?t=2057818
Any driver for a multiuser OS that essentially bypasses protection mechanisms by the kernel for non-root users is broken, period.
There is no argument about it.