HP Inc. seems to be on the radar of SentinelOne’s SentinelLabs researchers. Several months ago they reported on a vulnerability in HP and Samsung printers. The researchers have now discovered something similar in a driver that belongs to HP’s OMEN Gaming Hub. The vulnerability has been given the “name” CVE-2021-3437. With a CVSS score of 7.8 (out of 10), it is less severe than the previous one, but still not trivial. HP has since released a proper patch. It has been available since July 27.
We already mentioned it in the introduction, the vulnerability we are talking about in this article has many similarities with the one earlier this year. A bad driver is again the culprit. This time not a driver for a printer, but for gaming peripherals, among other things. This driver is part of the installation of the HP OMEN Gaming Hub software, which comes standard on all HP OMEN desktops and laptops. The software is also in the Microsoft Store. So you can install it on other Windows machines as well. The software can be used for customizing your peripherals, but also for optimizing settings of, for example, the GPU, the fans and overclocking the CPU and memory.
Sloppy developing once again
The driver in question (HpPortIox64.sys) is another one with some flaws. It can be found in the following directory: C:″Windows System″: HpPortIox64.sys. As with the previous vulnerability, HP has used an already existing and not particularly good driver to develop its own driver. In this case, it is the WinRing0.sys driver originally developed by OpenLibSys. Below you can clearly see that this is the case. The name of the original driver and its developer is still in the metadata of the HP driver.
The problem with this driver is that it is possible to get from User Mode to Kernel Mode via IOCTL (Input/Output Control). This escalation, as it is called in cybersecurity jargon, is potentially very dangerous. This is because it allows attackers to get to parts of your systems where they can do a lot of damage. The access to Kernel Mode seems to have been deliberately exposed by the developers of the driver. This isn’t necessarily a mistake, by the way. Sometimes, this is necessary for a driver to work optimally. There is no need to overflow a buffer by flooding it, as was the case with the printer driver earlier this year.
With IOCTL codes 0x9C4060CC, 0x9C4060D0, 0x9C4060D4, 0x9C40A0D8, 0x9C40A0DC and 0x9C40A0E0, you can write 1, 2, or 4 byte reads to or from an IO port in User Mode with few privileges. This is reminiscent of the earlier Dell computer vulnerability discovered by SentinelOne. You can read more about this via this link.
Two examples
During the research, the folks at SentinelLabs managed to do things by using the IOCTL codes above on internal storage that shouldn’t be possible. For example, it was possible to use the driver to communicatie directly with the IO ports for the ATA controller. With this it was possible to write directly to the internal storage, overwriting data (in the case of the example a binary) placed there by a priviliged process. In this particular case the machine did not boot up after that. SentinelOne’s action had broken the first sector of the disk.
Another example has to do with Model-Specific Registers (MSRs), more specifically the arbitrary reading and writing of them and to them. MSRs allow you to read or modify CPU data. Via IOCTL codes 0x9C402084 and 0x9C402088 you can access them with this driver. Since you get into Kernel Mode with this driver via MSR, these “open doors” make it pretty easy for malicious people to get there. The LSTAR MSR with which most modern systems go from User Mode to Kernel Mode can even be overwritten without requiring admin privileges. You simply overwrite the privileges and are in. There is no ACL (Access Control List) in this case. The latter is of course very important when working with exposed parts in a driver. Also, it is not smart to expose a generic interface to Kernel Mode activities.
Not actively exploited, patch available
As is almost always the case with these kinds of disclosures, there are no known cases where malicious people have used the vulnerability. This always makes us wonder how big the problem really is. Mind you, we don’t think it is unimportant to address and patch an issue like this. Apparently, however, there are better, faster or otherwise more attractive ways for hackers to get in.
This particular vulnerability is, of course, very easy to use (or rather abuse), which makes it something you should address as soon as possible. HP has done just that. Since July 27 a patch is available. For a company that has focused so heavily on security in recent years, both for PCs and printers, however, this revelation is once again a bit embarrassing for HP. Like last time, this is about sloppy development. There’s nothing wrong with using and modifying an existing driver, but you should do it right.