Top 5 Linux Kernel Vulnerabilities in 2018

June 19, 2018 Patricia Johnson

Along with the GNU Project. Linux is inarguably one of the OGs of the free and open source software community and ever expanding family of products.

Linux has been around since the early 90’s, when Linus Torvalds, then a student, created a free new kernel for his PC’s operating system. The kernal was released at first under a license Torvalds created, prohibiting commercial use, and soon after adopted the GNU GPL license.

The Linux kernel quickly became the go-to for developers and users, who in turn implemented it in their own free and open source projects. Today, it has a huge community behind it, supported by contributions from 12,000 developers from over 1000 companies, including industry giants like Intel, Red Hat, IBM, Samsung, Google, and Microsoft, to name a few, who have helped it evolve into the 23.3 million lines of source code in Linux kernel v4.15 released this year.

What Are the Most Common Linux Vulnerabilities in 2018?

We’ve put together a list of the top 5 Linux Vulnerabilities that hit organizations so far in 2018, aggregated by the WhiteSource database, which is updated continuously from the National Vulnerability Database (NVD), that most developers and security professionals know and love, as well as additional open source publicly available, peer-reviewed security advisories. Some of these might have been first uncovered before 2018, but are still alive and kicking in many systems.

 

#1 CVE-2017-18017

Linux Kernel netfilter: xt_TCPMSS

Vulnerability score: Critical — 9.8

Affected versions: Linux kernel before 4.11, and 4.9.x before 4.9.36

You might recognize this oldy-but-goody from our post covering top open source vulnerabilities in 2017. This comes as a reminder that vulnerabilities won’t just go away if they are not attended to. Organizations that are still using this vulnerable version need to remediate before the hackers locate it.

This component sits on the Linux kernel, and helps filter network communication by defining the maximum segment size allowed for accepting TCP headers. These controls are crucial to avoid overflow.

By exploiting this vulnerability, hackers can send through a flood of communications, and throw  the system off line in a denial of service (DoS) attack. Kernel level vulnerabilities are at the foundation of the system and can have wide ranging effects across the board, making this a critical vulnerability with a CVSS score of 10.

You can see the full list of vulnerable versions here.

The hardworking folks at Linux kernel have provided a fix, and detailed information about it can be found here.

 

#2 CVE-2017-18202

mm/oom_kill.c file

Vulnerability score: Critical — 9.8

Versions: before 4.14.4

This vulnerability lies in the mm/oom_kill.c file in the Linux kernel, a file that helps us kill a process when memory runs low. Vulnerable versions of the file might mishandle gather operations, opening the door to DoS attacks, or possibly triggering a copy_to_user call within a certain time window.

Happily, the Linux kernel community has got us covered. You can learn more about the vulnerability and its remediation here, here and here.

 

#3 CVE-2017-15126

fs/userfaultfd.c

Vulnerability score: High — 8.1

Versions: before 4.13.6.

The security issue in this kernel vulnerability is local memory corruption. More specifically, this is a use-after-free vulnerability, a specific type of memory corruption bug that can be exploited to execute arbitrary code or even enable full remote code execution.

In this case, the flaw was discovered in fs/userfaultfd.c in Linux kernel versions preceding 4.13.6, and is related to the handling of fork failure when dealing with event messages. This issue could be exploited by hackers to execute arbitrary code in context of the kernel. Failed exploit attempts can result in a DoS

The vulnerability and its fix have been published on a number of security advisories and bug trackers, and as usual, we’re here to let you know where you can find them. For more information about remediation you can check here, here and here.

 

#4 CVE-2018-1000026

bnx2x network card driver

Vulnerability score: High — 7.7

Versions: at least v4.8 onwards

This one is an insufficient input validation vulnerability affecting the bnx2x network card driver in the Linux kernel from version 4.8 and above. An attacker can exploit the vulnerability by passing on a very large and specially crafted packet to the bnx2x card from an untrusted guest virtual machine, knocking it offline and causing a DoS to the targeted system.  

Remediation for this sticky issue can be found here and here.

 

#5 CVE-2018-8822

NCPFS implementation

Vulnerability score: High — 7.8

Versions: through 4.15.11, and in drivers/staging/ncpfs/ncplib_kernel.c in the Linux kernel 4.16-rc through 4.16-rc6

This Linux kernel security issue is in vulnerable versions of the NCPFS implementation in the Linux kernel, because it doesn’t perform sufficient boundary-checks on user-supplied data, or validate reply lengths from the server.

This could allow attackers to exploit these memory corruption vulnerabilities to execute arbitrary code within the context of the affected device. Failed exploit attempts may result in DoS or remote code execution in the client.

Along with all the previous issues, this one also has published fixes. You can read about them here, here, and here.

 

Keep a Close Eye on Your Open Source Security

This list shows us, once again, how vigilant the open source community is with security vulnerabilities. This means that security experts are working continuously to ensure open source libraries are protected, and that the various trackers and security bulletins are updated with new vulnerabilities, updates, and patches.

The Linux community’s active and ongoing support of components is only the first step. It’s up to us to take it from there. We are responsible for always knowing which open source components and libraries are in our code, and which need a fix. In the wild west of the open source community, the only way to ensure we’re on top of our open source security is to adopt the DevSecOps approach, using automated and continuous tools to track our open source components, immediately report any issues that might arise, and give us all the information that we need in order to remediate, with as little disruptions to our timelines as possible.

Linux is an excellent example of how open source supports commercial software, and being part of this thriving community allows us to develop and deliver better software faster, but also requires us to actively track community updates and take action when necessary.

 
Previous Article
3 Key Considerations for DevOps Automation
3 Key Considerations for DevOps Automation

Next Article
9 Great DevSecOps Tools for Dev Teams to Integrate Throughout the DevOps Pipeline
9 Great DevSecOps Tools for Dev Teams to Integrate Throughout the DevOps Pipeline