Slashdot Mirror
Microsoft: Windows 10 Devices Open To 'Full Compromise' From Huawei PC Driver (zdnet.com)
According to ZDNet, researchers at Microsoft have discovered a buggy Huawei utility that could have given attackers a cheap way to undermine the security of the Windows kernel. From the report: Microsoft has now detailed how it found a severe local privilege escalation flaw in the Huawei PCManager driver software for its MateBook line of Windows 10 laptops. Thanks to Microsoft's work, the Chinese tech giant patched the flaw in January. As Microsoft researchers explain, third-party kernel drivers are becoming more attractive to attackers as a side-door to attacking the kernel without having to overcome its protections using an expensive zero-day kernel exploit in Windows. The flaw in Huawei's software was detected by new kernel sensors that were implemented in the Windows 10 October 2018 Update, aka version 1809.
The kernel sensors are meant to address the difficulty of detecting malicious code running in the kernel and are designed to detect user-space asynchronous procedure call (APC) code injection from the kernel. Microsoft Defender ATP anti-malware uses these sensors to detect actions caused by kernel code that may inject code into user-mode. Huawei's PCManager triggered Defender ATP alerts on multiple Windows 10 devices, prompting Microsoft to launch an investigation. [...] The investigation led the researcher to the executable MateBookService.exe. Due to a flaw in Huawei's 'watchdog' mechanism for HwOs2Ec10x64.sys, an attacker is able to create a malicious instance of MateBookService.exe to gain elevated privileges. The flaw can be used to make code running with low privileges read and write to other processes or to kernel space, leading to a "full machine compromise." Long-time Slashdot reader shanen writes: Though the story features Huawei, there doesn't seem to be anything specific to that company there. Just innuendo that you can't trust Chinese companies, eh? "Don't throw your computer into that Chinese briar patch!" Anyway, the sordid reality is that Microsoft is the root of all evils in the Windows platform. If increasing security had been half as important as maximizing profits, then we'd be in a much better world today. All complicated software is buggy, but adding complexity for no good reason is just begging for more problems. Here's a crazy solution approach: Any OS feature that isn't used by a LARGE majority of the users should be REMOVED from the OS. Maybe that isn't strong enough. Maybe the OS should be strictly limited to what absolutely needs to be there. Guard those eggs carefully!
The kernel sensors are meant to address the difficulty of detecting malicious code running in the kernel and are designed to detect user-space asynchronous procedure call (APC) code injection from the kernel. Microsoft Defender ATP anti-malware uses these sensors to detect actions caused by kernel code that may inject code into user-mode. Huawei's PCManager triggered Defender ATP alerts on multiple Windows 10 devices, prompting Microsoft to launch an investigation. [...] The investigation led the researcher to the executable MateBookService.exe. Due to a flaw in Huawei's 'watchdog' mechanism for HwOs2Ec10x64.sys, an attacker is able to create a malicious instance of MateBookService.exe to gain elevated privileges. The flaw can be used to make code running with low privileges read and write to other processes or to kernel space, leading to a "full machine compromise." Long-time Slashdot reader shanen writes: Though the story features Huawei, there doesn't seem to be anything specific to that company there. Just innuendo that you can't trust Chinese companies, eh? "Don't throw your computer into that Chinese briar patch!" Anyway, the sordid reality is that Microsoft is the root of all evils in the Windows platform. If increasing security had been half as important as maximizing profits, then we'd be in a much better world today. All complicated software is buggy, but adding complexity for no good reason is just begging for more problems. Here's a crazy solution approach: Any OS feature that isn't used by a LARGE majority of the users should be REMOVED from the OS. Maybe that isn't strong enough. Maybe the OS should be strictly limited to what absolutely needs to be there. Guard those eggs carefully!
Personally I’m highly suspicious of Huawei and I don’t think this was a flaw. “Intended design” is what I suspect is a better description.
Well, there's spam egg sausage and spam, that's not got much spam in it.
A sound law, only modules that are allowed to run in OS space by default, by law, should only be modules that allow 'operating systems functions only', all other modules by law, should be optional for the user to use. Optional and by default off, anything that spies on the user and transmit data off the computer, any modules that access the internet for any kind of software installs, all network access and that includes user choice as to what connections are allowed, any application add on modules that are not core operating system specific should be banned as being anti-competitive and a corruption of the term Operating System.
For any program to call itself an Operating System and to be recognised as such by the public must be purely an operating system, on top of which the user chooses which applications they will run. Force companies to drop the term 'Operating System' when it ceases to be one, as a result of added applications, invasions of privacy apps, forced software install apps, hard drive analysis and data deletion apps, any module, that is not operating system specific should be banned, it is by law false advertising.
So, like a Big-3 car then.
According to ZDNet, researchers at Microsoft have discovered a buggy Huawei utility that could have given attackers a cheap way to undermine the security of the Windows kernel.
What is that? I did not know the Windows kernel HAD security to begin with.
LOL MicroFail
Wait up there, Windows 10 is compromised by default. It includes software that invades your privacy, analyses your data and your internet access and does not inform you what it sends and specifically purposefully has been done in a way to block users for turning it off reliably (they shit cunts routinely turn it back on, purposefully). It forces the install of programs without user choice and that includes altering defaults, running advertisements and basically turning over control of that 'NOT-personal computer', to a blatantly corrupt for profit corporation, as a conspiracy between that 'CUNT' corporation and the equally corrupt USA government.
Chaos - everything, everywhere, everywhen
I'm so woke I'm stoked. I'm so woke I have morning wood all day long.
LOL MicroShill...
Nothing MicroShit makes is better than anything Apple makes, and I do not that much like Apple or their modern crappy, overpriced, defective-by-design SHIT. Microsoft is WAY worse, bad as Apple has gotten.
None of your comments have anything to do with the problem that Microsoft found. The folks in Redmond have put a lot of work into Windows 10 security while trying to retain the current partner ecosystem and backwards compatibility.
Here's a crazy solution approach: Any OS feature that isn't used by a LARGE majority of the users should be REMOVED from the OS. Maybe that isn't strong enough. Maybe the OS should be strictly limited to what absolutely needs to be there. Guard those eggs carefully!
While this looks to make sense at first sight, it is flawed.
Suppose there are a 100 functions that less than 5% of the users use. Removing each of them will only affect 5% of the users. Removing all of them might affect nearly 100% of them users, as each of them needs another feature to work.
I do agree on MS' bad reputation when it comes to security, but even that was not the root cause here. Their driver approval process needs might need more attention.
Or maybe something absurd as, say, open-source drivers? Ideally the whole kernel and driver stack would be OS. Maybe in the future law will require such, for safety and accountability. They can keep their other junk like office closed afaic.
A glitch a day keeps the bugs away.
Malice, negligence or just "shit happens", low-level hardware drivers are a problem. The protection is pretty much the same no matter how the vulnerability got there.
Hardware drivers and the kernel require powerful capabilities - and are responsible for ENFORCING security policy. Since they control security, they can't be controlled by it.
At one point people developed the idea of the microkernel as a theoretical way of reducing the attack surface. In practice, that evolved into virtualization - the hardware drivers being separate from the application software, to the extent of being two separate operating systems. Virtualization gives a good layer of security (though nothing is perfect).
Another good solution is exemplified by USB 2.0, where the hardware driver is stored within the hardware itself, as firmware, and totally separate from the operating system. The OS trusted driver needs only be a generic driver that an talk to that class of hardware via a standard interface protocol.
Thunderbolt goes the opposite way, exposing your PCI-E bus to externally connected devices, giving them the same level of trust as internal parts.
Microkernels are looking better all the time.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Good one. How about, instead, people who don't have use cases that require a very flexible OS should stick to iOS?
Long-time Slashdot reader shanen writes:
Any OS feature that isn't used by a LARGE majority of the users should be REMOVED from the OS.
Yeah... fuck you. Every piece of software is being gimped like crazy to cater to the lowest common denominator, and features I need are being wiped out every day in the name of improving my experience. Microsoft already requires signed drivers, so whatever happened here is purely a political problem, not a technical one.
If Huawei is installing some stupid "helper" that fucks up the machine, I won't buy a Huawei. I'll build the machine myself and use an OEM copy of Windows, just as I have been doing for the last 20+ years. The last thing I want is for Microsoft to lock down the system even more to ensure I have even less control of my machine.
For the record, I stopped upgrading at Win7. I won't touch Win10 with a barge pole.
Mod this comment to 100000
The problem is half assed OS design.
Drivers are dangerous.
Adobe Flash by about 10 and Cisco by about 100 times I guess.
Because they are slightly less efficient. Maybe 10%.
And nobody would tolerate a computer that is 10% slower just because that is secure.
If increasing security had been half as important as maximizing profits
FIRST you make it work, THEN you make it faster, and ONLY THEN you fix the security.
Right? You get first / early to market your product and you make it faster and better as people accept and purchase it. Once you've got a large enough customer base who "can't live without it" you hit them up for the security charges. If you had done that at the beginning, it would have cost more and been released later to the detriment of sales.
Besides, if you'd really wanted security you would have purchased a different product in the first place. If "all bugs are shallow given enough eyes", then "no bugs exist if no one's looking" -- and it's CHEAPER that way, too.
If the universe is someone's simulation -- does that mean the stars are just stuck pixels?
FIRST you make it work,
THEN you make it faster,
and ONLY THEN you fix the security.
You, Sir, must have been working for Boeing !!
That's not how USB 2.0 works. The "hardware driver" is not stored within the hardware itself.
Microkernels provide some isolation to mitigate the problem, but they don't provide total security.
The driver for the crappy USB multi-function device is a separate process from the filesystem driver process, so it's safe, right? Just imagine that a bug in the crappy USB device's UI allows you to send commands to the device that trigger a bug in the filesystem driver that manifests a code injection vulnerability. Now you are running code in the filesystem driver so it's game over. You can read and write every file on disk, or substitute your own!
Really one of the biggest problems is that hardware companies are mostly shit at writing software, and device drivers are the hardest kind of software to write. They have to interact with low-level OS APIs that are designed to be high-performance rather than high-level abstractions. They have to be multi-threaded, reentrant, or whatever else is required to be scalable on multi-core systems because nobody wants 15 cores to be idle while the single-threaded network driver processes requests for all the other cores.
dom
Users did NOT choose for Microsoft to unilaterally fuck over the software stack to fuck over their captive audience.
How stupid do you think we are?
Please feel free to visit the latest Linux Kernel tree (or any for several years) and audit the code for the included ESXi drivers (memory management and network specifically) as well as the Cisco VIC network and SCSI driver code.
... which include entire built-in processors for SCSI and RDMA... so that you could pretend to be one of the VMs and communicate to anywhere you want and even issue SCSI requests to the SAN directly over network protocols that can't be monitored on Cisco switches.
It took me an average of 3 minutes between finding attack vectors thanks to VMware's half-assed code that should have been completely rewritten years ago. Now, if you can't find a vulnerability using the ESXi drivers in the Linux code base, you probably shouldn't be allowed near a computer.
The Cisco VIC adapter code is so much better... you not only can find endless numbers of vulnerabilities, but you can actually upload entire new operating systems to the VIC adapters in nearly all Cisco servers (especially HyperFlex) and you can even change the boot firmware by disabling authenticity checks in the driver code. The end result being that you could easily permanently place undetectable backdoors that would require hardware replacement to correct into the VIC adapter.
Even better... as a bonus, I'm quite confident that it is possible on VMware from a guest machine using VMFEX network adapters with Cisco VICs, it should be possible to change the hardware firmware of the VIC adapters
None of this is intentional... it's all because no one takes the time to clean up after their own messes.
Indeed. Drivers are trusted. That means they can break your security and there is nothing that can be done about it. As to malice, that seems highly unlikely, as this issue would have been better hidden. In particular, the attacker would have made sure these "sensors" do not detect it. A placed backdoor loses most of its worth after it has been found. No, this is just a regular screw-up that stems from the fact that the world still has not learned that software is hard and that people doing it well need talent, expensive and intense education and experience and that nothing else will serve. Getting more cheaper coders will just allow you to produce more errors in less time.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Instead we run anti-virus to hopefully catch some of the problems that might slip through the insecurities. How much overhead is that you ask?
The engineers at Huawei know exactly what they're doing, they just didn't hide it well enough this time. The purpose of this "flawed" driver can be none other than to provide a hacking capability that is as widely distributed as Huawei phones, since every one of their phones wherever it ends up in the world will have the "flaw". Of course, anybody with half a brain and any importance should now be avoiding Huawei hardware like the plague. When the Department of Defense, the CIA, the NSA and GHCQ tell you that Huawei hardware has backdoors and will be used to spy on you, maybe that's worth listening to? What distinguishes Chinese hardware hacking is their greed and low level of respect for their adversaries. Sure, by baking the compromise into every board you produce it gets as widely distributed as possible, but it also massively increases the chance, practically to a certainty, that it will be found. This is why more sophisticated Western intelligence agencies engage in tailored operations instead, compromising only those specific pieces of hardware that are on their way to intended targets. The benefit is two fold. First, you don't have a lot of noise to filter out to get at the signal, because only interesting targets are monitored, and second the low numbers of compromised devices reduces the chance that the modifications will be discovered and even if they are discovered the targets are likely to simply destroy or discard the devices because nobody likes to admit that they have been hacked and nobody else can corroborate the discovery because not every device has the hacking hardware burned in.
or Chrysler. I saw one blowing smoke at the highway here in Europe when they were rare.
Probably by design. After all, it was the only code section with English comments.
No sense in looking any further, problem solved. All good now.
Or maybe something absurd as, say, open-source drivers?
Well, if you call it a MATEbook, I expect it to run Linux with the MATE desktop environment.
Nae king! Nae laird! Nae yurrupiean pressedent! We willna be fooled again!
As to malice, that seems highly unlikely, as this issue would have been better hidden. In particular, the attacker would have made sure these "sensors" do not detect it.
I have to point out that the "sensors" were new, so malice is still an option. Of course there were beta versions of Windows Update 1809 before the actual update came out, a true malicious operator would have had time to attempt an update to the driver to at least hide the side-door.
fwiw, I'll vote for a screwup.
Mielipiteet omiani - Opinions personal, facts suspect.
Z^-1
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
Huawei will have access to all previews and likely is part of a select small group that gets them even earlier, so that is not a very strong argument. As malicious actors can be incompetent too, it is not a worthless argument, just weak. But Hanlon's Razor has stood the test of time and is usually right.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
So you're the guy who fell for it and downloaded the "driver" for the thumb drive you bought?
USB devices present themselves to the OS as one of 21 classes, such as:
01 Audio Speaker, microphone, sound card, MIDI
02 Communications Modem, Serial, Ethernet
03 Human interface device (HID) Keyboard, mouse
05 Physical Interface Device (PID) Force feedback joystick
06 Image (PTP/MTP) Webcam, scanner
08 Mass storage (MSC or UMS) USB flash drive, memory card reader, digital audio player
Note "storage device" doesn't distinguish between a flash drive and a spinning disk. The OS tells the USB device "store these bytes" or "play this sound". The OS has no idea how the hardware actually does that. Firmware within the device knows about the memory chips whatever hardware is involved.
If you lookup which chips devices can use to implement USB, you'll notice all the USB interface chips have flash memory included in the chip. Wonder what that's for? :) That's for storing your hardware driver, within the device.
The other option for implementing a "USB device" is to use a ft232rl USB to serial converter or similar in your device, then build a serial device. In that case the actual USB device is the USB to serial port, which then has a serial device attached.
Something is broken with the moderation function today
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Why would you want to run more than one program at a time anyway?
And what moron would want to have more than 640K of memory?
"Maybe the OS should be strictly limited to what absolutely needs to be there."
Nowadays people expect their OS to run on a variety of hardware, support all of it, support all kinds of devices plugged into the USB-port at once, do all that with a GUI that allows an image to be dragged from one piece of software to another one with a mouse movement and hides all the gritty details under the hood. Why wouldn't they? That is not only so for PCs running under Windows, but for Linux-machines as well.
I fully support, that a coffee machine doesn't need to be able to host web pages (although there might be use cases even for that), but a PC/Laptop is a multi-purpose-tool, its value lies in its flexibility, the ability to connect to a variety of periphery and run an even greater variety of software, and the (comparatively) low pricing possible due to not tailoring every PC to the specific needs to its user, but selling everyone the same multi-purpose tool of which most users only use a small subset.
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
Any OS feature that isn't used by a LARGE majority of the users should be REMOVED from the OS.
third-party kernel drivers are used by nearly all 3rd party hardware manufacturers. So why even bring this up? Is this some kind of systemd dog whistle or what?
Hardware drivers and the kernel require powerful capabilities - and are responsible for ENFORCING security policy. Since they control security, they can't be controlled by it.
Can't the drivers be constrained by the combination of MMU and IOMMU?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Can a device driver access your hard drive? Yes, that's what the sd and ahci drivers are FOR. If the sd driver couldn't access your block devices, how would anything access them? If the ahci couldn't access your SATA controller, you couldn't use your SATA controller.
Can device driver's access your network card? Pretty tough to use a network card if drivers can't read it, write it, and otherwise control it.
So the hardware drivers must, at minimum, have access to and control of your hardware - and therefore all your data.
Yes if you design a system where (really slow) device drivers run as separate processes, you could use the MMU to limit which *memory* it has access to, but still drivers have control of hardware.
Here I say "hardware drivers" not to be redundant, but because you CAN have a userspace driver which adds certain *functionality* to be accessed *through* a piece of hardware, which in turn has a hardware driver. A classic example is a modem attached to a serial port. At least from the perspective of the kernel, the hardware is the serial port. That hardware must be controlled by a hardware driver which has full control of the hardware. The hardware driver can accept requests from the userland modem driver. I've written drivers like that before. The userland modem driver doesn't need direct control of hardware, it can go through the serial port driver and any security gates we decide to put in.
Don't you dare to buy Huawei, cos a random driver for obsolete operating system is exploitable.
Every driver for any Windows is exploitable, and has always been so.
This article is american lies, trying to discredit a manufacturer that won't implement the american backdoors.
Why does this get a whole article on slashdot?
Subject: is a joke,but I can only clarify with a thought experiment that Microsoft probably tried and failed to implement. So help me gawd, but I actually think the idea underlying Clippy was not bad. It couldn't be done at the time, and now the entire approach has been tainted. If there were more "real" players at the OS level I think someone would have implemented it by now.
The OS should be quite aloof from what you want to do. The OS should be primarily a facilitator for applications. At the meta-level, that includes helping users find applications and helping the applications add the features and functions you actually want and need. As much as possible, that should be handled invisibly, by inference.
For a simple example, if you receive a file with a peculiar font, then the capability for that font should be added to your system without bothering you. The font should be downloaded and installed (or perhaps held in temporary storage with the temporary document if the user prefers that or if the machine has too little memory).
For a more complicated example, what happens when you want to use a different font? The failed Clippy approach might have involved an intrusive dialog like "I see you've been poking at the font menu for a while in a way that indicates you can't find the font you want. Would you like to add more fonts to your font menu or do you need help finding a specific font?" We can do better now. Let me test my voice dictation to be sure... Yes, it works well enough. I can say "I want a flashy modern font[s] with high[-]impact for [an] advertising brochure" and it is recognized well enough for me to take the initiative. Death to Clippy again! (Can't say that enough.) I don't need Clippy when I know what I want--if the OS could just respond to such statements.
As I visualize and imagine it, my computer would only have the features I actually use or am highly likely to want to use. Extremist that I am, that would go all the way down to the applications, with the OS helping applications to install the extra features as need arises, or even recommending changes in applications. Not far enough! The OS would configure the new (or upgraded) application to match my previous configuration as much as possible and even guide me to the better ways of doing things that I want to do. And yet I should still be able to insist on doing things differently even if the OS has to work harder to make it possible!
In my delusion, individual computers would be quite different and there would be very few points of massive attack. Those would obviously be the foci for the security experts...
Enough dreaming for now. It ain't going to happen because it would cut into the massive profits of the giant corporate cancers. The only real players now are Microsoft and Apple and the google, and I don't see any evidence they are considering such approaches nor any competitive pressures that could change their minds. In this context, Linux is not regarded as a "real player" because there is not enough development money to support the approach (or it would have been implemented already).
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
So the hardware drivers must, at minimum, have access to and control of your hardware - and therefore all your data.
No. Each individual driver needs access to and control of one piece of hardware. You're grossly misstating the case.
Yes if you design a system where (really slow) device drivers run as separate processes, you could use the MMU to limit which *memory* it has access to, but still drivers have control of hardware.
Um, yeah, that's what the IOMMU is for. All modern PCs have them.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Okay, Mr. Kernel, does the driver kbdray handle a Microsoft Natural keyboard? By the way, that driver is newwer than the kernel.
Go ahead and take your time answering, I'll wait.
.
.
.
.
.
.
.
.
.
.
.
.
.
How can a kernel (from last year) figure out what hardware is supported by a driver (which was written last week)? Where is the code that knows which hardware is supported by that driver?
The driver knows which hardware it supports! The kernel figures out which driver goes to which hardware by asking the driver. On Linux, for example, udev does the poll. It actually has two methods for asking drivers what hardware they support. The simplest method is udev can call a function within the driver, passing the type and vendor IDs to the driver. The driver then responds yes or no. The other mechanism is the driver can call driver_register, passing it's device_driver structure which includes a list of which hardware it supports.
I highly recommend before you tell me any more about how we write drivers, you try actually writing one. If you're on Mac, there's one we need. What it needs to do is claim a particular memory segment for itself, then use that memory to - do nothing. That segment has a few bad bits, and should not be used. Very handy on MacBooks with soldered-on RAM.
If you DO decide to write a simple driver as a learning exercise, here's a little tip:
> Each individual driver needs access to and control of one piece of hardware.
Somebody might have TWO audio cards. Or FOUR disks. Maybe even zero SCSI cards. In your code, remember basically everything needs to be a linked list, because you may be handling one, two, twenty, or zero pieces of hardware. Also other drivers may claim the same hardware, so be ready for that.
I not sure that I understand the sentiment of the article is this in relation to the narrative that Huawei is evil because they complete with Apple?
people have to learn that any piece of closed source software cannot be trusted.
in case of drivers this is even more so, whatever the design of the OS might be, even if the OS itself is fully OSS, a closed driver takes all those advantages go away.
On a long enough timeline, the survival rate for everyone drops to zero.
Not the previous AC, but I've actually implemented commercial drivers for USB 2.0.
This is not how this works.
There exist generic USB classes, which can be implemented with a generic driver.
Even for some of these, there might be vendor specific drivers to handle the additional interfaces. (With CDC ACM/ECM (Serial and Ethernet) devices historically often having the interfaces defined as vendor specific anyway, and the driver installation sometimes just configured a generic driver for these, but built-in support in Windows used to be quite weak.)
There also exist a whole bunch of non-standard devices, which wouldn't work without their relevant driver.
In any case, there's still a driver involved (possibly from the OS vendor), and bugs there can still bite you (especially since driver logic might not be trivial)
A device might present a Mass Storage device to allow driver installation (this is done by a bunch of modem dongles).
Btw, USB 2.0 Mass storage is mostly SCSI over USB.
If your host lacks a driver for a device class, you won't be able to use the device.
Of course, the device has its own firmware which controls the USB device controller to communicate with the host, and the internal hardware.
Z^-2
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.