I mean, it's goofy, hacky, and has obvious security flaws but doesn't look malicious. Calling it a "backdoor" ascribes a certain intentionality to the vulnerability that's not clear is warranted. It's about the code quality I expect from the management shovelware that comes preloaded on laptops from any major brand.

Source: I've written kernel drivers and exploits.

What is not malicious about a driver whose pure function (this thing literally has no other value or purpose) is maintaining an invincible NT_AUTHORITY process of their pre-installed management software? And achieving that by allocating a RWX page in services.exe? What are we even doing W^X for?

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):

https://consumer.huawei.com/us/support/pc/matebook-x-pro/

> What is not malicious

> 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.

> I see nothing about how this driver doesn't have any other functions.

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.

Quote the piece of the article that says that the driver has no other functions.

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.

Writing "drivers" that do questionable things for even more questionable reasons seems to be par for the course in the Windows ecosystem. If I understand the whole situation correctly, Fortnite installs WHQL certified kernel driver, whose sole purpose is to cause BSOD when LSASS.EXE maps pages from the Fortnite process...

Is that an anti-cheat feature?

As if the same OEMs would constrain themselves when targeting other platforms.

On the other hand a reliable backdoor that also looks like sloppy code is better, as most of us are familiar with truly awful code it’s a nice layer of plausible deniability.

As the full saying goes.

Never attribute to malice what can be explained by stupidity...but don’t rule out malice.

By that logic we should be calling all vulnerabilities "backdoors" just in case.

Perhaps you should because the end result is the same, shit code sinks ships. Somebody could have written it intentionally or somebody could have been a dumbshit. Doesn't matter to me because now my computer is compromised.

I mean, the term 'backdoor' has a connotation of intentionality. Unless you write perfect code 100% of the time, you probably rely on the difference.

Freetype buffer overflow leads to privilege escalataion.

All code is security code.

Definitely don't disagree, but are the freetype developers being malicious when they leave in a bug?

>All code is security code.

Debian disagrees. They are wrong to do so.

The microsoft article mentions that Windows Defender caught multiple machines performing kernel injections near the same time with this driver as the root cause. Meaning it was already being exploited.

This doesn't mean the actual flaw was malicious, but being actively exploited, it seems intent doesn't really matter.

I don't see anything saying this was being actively exploited; the non malicious use case would set off their scanners on all MateBooks running this driver.

from the article:

> 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)

> via the exploited code

Their scanner doesn't show any exploitation happening, and they don't say that it does.

I admit that I am reading into the line "abnormal memory allocation and execution" and thinking it's intentional.

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.

It's intentional; it's not "exploitation". It's really doing privilege deescalation of the shellcode.

They know the code it's running for the most part, it's the CreatProcessW stuff they talk about.

From Microsoft’s blog post:

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?

...because it's the hardware management service and if it goes down you're no longer managing the hardware?

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.

>...because it’s the hardware management service and if it goes down you’re no longer managing the hardware?

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.

Device Manager only handles kernel drivers. Best practice is to put as much as possible into a highly privileged, but still user mode process so it can crash without bluescreening your system. If you assume that this code can crash (hence why it was delegated to user mode in the first place) it makes sense to code in a resurrection capability.

Windows services have a restart if I crash mode, why wouldn’t that be used instead. This seems about making sure the user can’t stop it from starting

It's a huge pain on the ass to setup right. Soft faults where the process is still running but is deadlocked don't get restarted for instance.

Same problem if you write your own supervisor except you are writing a process supervisor

Well, no, because you can write your supervisor in a way that does protect against that. In fact that's hat they're doing here.

Not commenting any way on the particular issue at hand, but to respond to your general question:

> 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.

Problem: any well written exploit will be designed to look like a mistake.

> I mean, it's goofy, hacky, and has obvious security flaws but doesn't look malicious.

Plausible deniability. If you were to implement a backdoor for a company, would you write "professionally done" all over it?

So now every bug on a privilege boundary is a backdoor, because of "plausible deniability"?

Did I say that? The point is that it just because it looks like an "honest mistake" doesn't mean it is. If you were to create a backdoor, that's exactly how you'd want to do it.

Given the circumstances, one might wish to err on the side of caution.

Have you heard of plausible deniability?

So now every bug on a privilege boundary is a backdoor, because of "plausible deniability"?

Then what other kinds of software need to use a privilege escalation?

The code is designed to be a privilege _deescalation_. It's already running in kernel mode, and is deferring work to a user mode process.

To create a backdoor, you could not be obvious. Like do something obviously evil in the driver... You'd build it out of many building blocks in several components that individually look like honest mistakes. "Mistakes" that can be combined to create something malicious.

That's what you need to achieve plausible deniability. You'll need to make it look innocent.

(I also write Windows kernel mode drivers.)

Did you think that the recent Apache privilege escalation exploit is a malicious piece?

Did your drivers also give usermode code the ability to map arbitrary memory addresses of the usermode code's choosing, thus granting full rw access to all memory pages in the system?

Either Huawei's driver developers are both incompetent and stupid or they're injecting malicious backdoors.

That's not what this driver does, you need to re-read the article.

> Having been able to freely invoke IOCTL handlers of the driver from user-mode, we looked for other capabilities that can be abused. We found one: the driver provided a capability to map any physical page into user-mode with RW permissions. Invoking this handler allowed a code running with low privileges to read-write beyond the process boundaries—to other processes or even to kernel space. This, of course, means a full machine compromise.

Please, continue.

Ok, I missed that part. Most people here are up in arms about the page mapping for the code injection.

But FWIW, it's a pretty common thing for shitty drivers. Here's one example: https://forum.xda-developers.com/showthread.php?t=2057818

Really? Because MS and others have stated what Huawei did here isn't unheard of.

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.

To be fair, doing things for which "There is no valid reason, ever" is not unheard of, especially in software.

Hanlon's razor - Never attribute to malice that which is adequately explained by stupidity.

Hanlon's razor is used by the malicious to fool the stupid. While we are spouting aphorisms, here's another one: "never say never".

Honest question: is it plausible that someone who is knowledgeable enough to understand and implement this exploit is also oblivious to ita exploitability?

Hell yes, device drivers and related tools are a cesspit of demon-worshipping excrements from outer space.

Since you make a very strong claim on a very complex topic, would you mind if I asked you to share whether you have expertise / credentials on drivers and security?

Edit: I'm not sure if it's considered appropriate to ask for credentials on HN. There's one way to find out :)

A driver allowing to map any page is like recording a magician from all angles.

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.

There's a lot of situations where you map in trampolines to perform work inside a process on behalf of that process.

The article is about a driver that allows to map any physical page.

That majority isn't.

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

I am not sure what you are trying to say.

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.

What is so complex about it? This is a very simple code injection technique ported to kernel space. Only, of course, there is essentially no use for code injection in any sort of production software.