Linux Kernel Security in a Nutshell: How to Secure Your Linux System

The Linux kernel is the core component of the Linux operating system, maintaining complete control over everything in the system. It is the interface between applications and data processing at the hardware level, connecting the system hardware to the application software. The kernel manages input/output requests from software, memory, processes, peripherals and security, among other hefty responsibilities. Needless to say, the Linux kernel is pretty important. 

However, with power comes great responsibility, and the Linux kernel is no exception to this rule. Kernel security is critical: it determines the security of the Linux operating system as a whole, as well as the security of every individual system that runs on Linux. Vulnerabilities in the kernel can have serious implications for Linux users, and it is extremely important that users stay up-to-date on news and advisories pertaining to kernel security.

In this article, LinuxSecurity examines how kernel security has evolved in recent years and how to mitigate your risk as a Linux user.

A Brief History of the Linux Kernel

The Linux kernel was created in 1991 by Linus Torvalds for his personal computer. Torvalds had no cross-platform intentions for the kernel; however, over the past two decades the Linux kernel has expanded and evolved to support a wider array of computer architectures than any other kernel or operating system. Not long after its conception, Linux began to attract developers, contributors and users worldwide and was rapidly adopted as the kernel for many free software projects, including the GNU Operating System.

Intro to Linux Kernel Security

Kernel security is a hot topic in the Linux community due to the fact that a large portion of kernel bugs present potential security flaws. For instance, vulnerabilities in the Linux kernel may allow for privilege escalation or create denial-of-service attack vectors. Many of the more severe vulnerabilities discovered in the Linux kernel result in attacks that can be carried out remotely without any actions taken by the victim. These attacks present a bigger threat than those that require hackers to have a local account.

In general, Linux is an exceptionally secure operating system, which can be attributed to the principles of transparency and collaboration upon which the OS was founded. However, as with any OS, security bugs are inevitable. Thanks to a supportive, passionate and active community, a large portion of the vulnerabilities that exist in the Linux kernel are identified and fixed before they become a significant problem. Others slip through the cracks and cause more grief before they are recognized and addressed. While there have been many more security vulnerabilities that have been found and fixed in the Linux kernel than the ones listed below, some of the most notorious bugs that have been discovered and remedied over the years include:

• CVE-2017-18017: This critical vulnerability, which exists in the netfilter tcpmss_mangle_packet function, is extremely dangerous because of the important role that it plays in filtering network communications by defining the maximum segment size that is allowed for accepting TCP headers. Without these controls in place, users are susceptible to overflow issues and DoS attacks. The flaw impacts versions before 4.11.
• CVE-2016-10229: This udp.c bug, also affecting versions prior to 4.5, allows remote attackers to execute arbitrary code via UDP traffic, triggering an unsafe second checksum during the execution of a recv system call with the MSG_PEEK flag.

• CVE-2016-10150: This use-after-free vulnerability affecting Linux kernel versions prior to 4.8.13 allows users to cause a DoS attack. This flaw could also be exploited by hackers to gain privileges.

• CVE-2015-8812: This severe vulnerability impacting versions prior to 4.5, which was discovered in the drivers of the Linux kernel, enables remote attackers to execute arbitrary code or cause a DoS (use-after-free) via crafted packets.

• CVE-2014-2523: This serious netfilter vulnerability, which impacts versions through 3.13.6, can be attributed to the incorrect use of a DCCP header pointer. The flaw allows remote attackers to cause a DoS (system crash) or to execute arbitrary code via a DCCP packet that triggers a call to either the dccp_new, dccp_packet, or dccp_error function.   

Balancing the Risks of Public Bug Disclosure

When a kernel vulnerability is identified, members of the Linux community collectively work to fix it. While this collaboration leads to rapid innovation and effective patches, the publication of patch proposals before their inclusion in the mainstream kernel branch does carry some degree of risk. Threat actors could potentially reverse-engineer a zero-day bug using patch proposals shared on the public mailing list. 

The community does have guidelines in place to mitigate this risk and keep patch proposals in the right hands until a patch is ready. A private mailing list exists for communicating with individual Linux distribution vendors, giving them time to prepare kernel patches in advance of public disclosure. However, the code for a patch eventually has to make it onto the public repositories that contain the source code for the Linux kernel. 

Greg Kroah-Hartman, a Fellow at the Linux Foundation responsible for the Linux kernel stable releases, explains: “There is no way to ‘hide’ our work or patches as everything we do is released publicly in our trees. So yes, if you really wanted to see what is ‘broken’ in Linux, you ‘just’ watch everything that is merged into the kernel tree as it has hundreds of fixes for problems every week.” This would be a difficult job, but by no means should be written off as impossible for a determined hacker, especially if he or she were to use ‘-next trees’, which collect likely patches for the next mainline merge window.

Kernel Security in 2019: Current Issues and New Security Features

2019 has been an eventful year for the Linux kernel. While kernel security is never stagnant, some notorious security issues continue to plague the kernel. One example is Intel’s persistent CPU problems, which have led to Meltdown and Spectre security issues. Zombieland v2, a security hole which allows hackers to gain read access to your data or to hang your system and can also be used against all recent Intel processors including Cascade Lake, is the latest of these problems. Greg Kroah-Hartman, the stable Linux kernel maintainer, recently commented on Intel’s notorious CPU issues, “These problems are going to be with us for a very long time, they're not going away. They're all CPU bugs, in some ways they're all the same problem, but each has to be solved in its own way. MDS, RDDL, Fallout, Zombieland: They're all variants of the same basic problem.” And securing your OS against these attacks as they appear is a tedious process which could result in a significant performance hit. For instance, disabling hyper-threading to protect systems against Zombieload attacks has been shown to decrease performance for certain workloads by 30% to 40%. In the words of a Chinese developer who recently spoke with Kroah-Hartman, “This is a sad talk.”

On a brighter note, this past month Linus Torvalds finally approved a new security feature, the Linux Security Module (LSM), nicknamed “lockdown”, to be included in version 5.4 of the kernel. The purpose of the feature is to restrict various aspects of kernel functionality, prevent modification of kernel code, and lockdown hardware that could potentially generate direct memory addressing, among other security benefits. The feature, which has been in the works since 2010, was engineered by Mathew Garrett as a way to prevent users with elevated privileges from modifying the Linux kernel code. Torvalds was initially opposed to the idea, stating that it was “nothing more than a means of getting Linux to boot on what would be Windows-only hardware”. However, with the lockdown feature now in place, Torvalds admits that it “gets us much closer to not requiring external patches”.

Another key security feature that is currently in the works is Kernel Address Space Isolation . Its implementation could potentially reduce the risk of leaking sensitive data in attacks like L1 Terminal Fault (L1TF), MDS, hyper threading and other vulnerabilities. Kernel Address Space Isolation would, however, increase the complexity of the kernel code and the impact that this would have on performance has not yet been evaluated.

How to Protect Your Linux System from Kernel Vulnerabilities: Tips and Best Practices for Administrators and Users 

While kernel vulnerabilities are often identified and patched fairly rapidly, it is up to users to take responsibility for maintaining a secure Linux system. Some best practices for protecting your system include:

• Track security advisories 
• Seek out and apply software patches as soon as they are released
• Update your system frequently - use automatic updates when possible - and don’t forget to reboot your system once the kernel is updated! (Note: Automatic updates are available for Linux and are often easier to set up and run than those available for Windows or MacOS users)
• When using a stable version, plan ahead and upgrade to the next version before official support is ended
• Implement proper firewall filtering policies
• Harden your server against SYN flood attacks
• Disable direct memory access (DMA) to prevent DMA attacks
• Create regular backups
• Set up system monitoring tools to avoid downtime

LinuxSecurity.com is a great resource for information on how to secure and harden your Linux system against kernel vulnerabilities. LinuxSecurity also tracks security advisories for thirteen popular Linux distributions, and has an RSS feed specifically devoted to advisories. 

Have additional questions about kernel security or how to secure your system that haven’t been addressed in this article? Do not hesitate to contact us. We would love to continue the discussion!