At the Linux Security Summit last month, Google developer Kees Cook shared the current workings of the Kernel Self-Protection Project (KSPP). The project, he said, goes beyond user space and even beyond kernel integrity. The idea is to implement changes to help the kernel protect itself.
To understand the importance of the project, Cook said, we need to think about the multitude of devices running Linux, such as servers, laptops, cars, phones, and then consider that the vast majority of these devices are running old software, which contains bugs. Some of these devices have very long lifetimes, but the lifetime of a bug can be longer still.
In 2010, Jon Corbet researched security flaws and found that the average time between introduction and fix was about 5 years. Cook’s own analysis of the Ubuntu CVE tracker for the kernel from 2011 through 2016 showed the following vulnerabilities:
-
Critical: 2 @ 3.3 years
-
High: 24 @ 6.4 years
-
Medium: 334 @ 5.2 years
-
Low: 186 @ 5.0 years
These risks, Cook said, are not just theoretical. “Attackers are watching commits, and they are better at finding bugs than we are.” To better protect devices, we need to build in protection from the start.
And, just because you have no open bugs in your bug tracker, does not mean everything’s fine. The important thing, he said, is to look at where problems were introduced and try to gauge what bugs are in the system now.
Cook used the analogy of the 1960s US car industry. At that time, cars were designed to run — not to fail. And, when they did fail, crashes were disastrous. The car industry had to figure out how to handle crashes safely, just as Linux needs to handle failures safely.
Cook further noted that user space is becoming more difficult to attack, which makes the kernel more attractive. And, whether we are comfortable with the idea or not, lives now depend on Linux.
Many people are working on excellent technologies that revolve around the kernel protecting user space, Cook said, but the developers working under the KSPP umbrella are focused on the kernel protecting the kernel from attack. The project aims to eliminate exploitation targets and methods, eliminate information leaks, and eliminate anything that assists attackers, even if doing so makes development more difficult.
Toward this end, killing bugs is nice, but killing bug classes is better. If we can stop an entire kind of bug from happening, we absolutely should do so, Cook said. He then described several bug classes, such as stack overflow, integer over/under flow, heap overflow, format string injection, kernel pointer leak (exposing kernel addresses), uninitialized variables, and use-after-free (which is related to integer over/under flow), and discussed possible mitigation approaches.
He then gave some examples of exploits and ways to mitigate them as well. In the case of the “Finding the Kernel” exploit, he said, possible mitigation approaches could be hiding symbols and kernel pointers, introducing runtime randomization of kernel functions, or implementing per-build structure layout randomization.
For the “Userspace Execution” exploit, mitigations include hardware segmentation, emulated memory segmentation via page table swap, and compiler instrumentation to set high bit on function calls. Cook mentioned he still needs this emulation for x86 in case anyone can help out.
He then detailed the changes that have been added to kernel versions 4.3 through 4.7 and described some changes that he expects to be added into 4.8 and even beyond into 4.9.
Cook admitted that the biggest challenge for the project is culture — and that the process requires persistence and patience on both sides. There are also technical challenges and, he said, collaboration plays a big role in overcoming those.
“Even if you have fantastic code, if you can’t describe why it’s needed, how it helps things, then really documenting these changes can be a big challenge.” And, he said, people need to understand they’re not writing for the kernel, they’re writing for the kernel developers.
“Other people are maintaining your code, other people need to understand your code, and other people are not necessarily familiar with what you’re doing, so making it understandable is critical.”
Watch the complete presentation below:
You won’t want to miss the stellar lineup of keynotes, 185+ sessions and plenty of extracurricular events for networking at LinuxCon + ContainerCon Europe in Berlin. Secure your spot before it’s too late! Register now.
