How To Fix The Most Common Linux Kernel Vulnerabilities

For this reason, developers need to have a complete understanding of common software glitches and vulnerabilities that hit the Linux kernel. This helps to not only minimize the chances of exploits but also improve the overall quality of the software you build.  

Most vulnerabilities in the Linux Kernel are associated with flaws such as SQL injection, uncontrolled format string, buffer overflow, integer overflow, and OS Command injection.

 Regardless of the weakness behind a vulnerability, there are three primary factors that determine its impact or severity. These are:

By exploiting known vulnerabilities, hackers may compromise a system by gaining root privileges, causing a system crash, or accessing the memory. In this article, we will walk you through three of the most common Linux Kernel vulnerabilities.
We will also dive into how you can detect and mitigate these vulnerabilities 

CVSS Score: 7.8
Affects Linux kernels 2.6.29 versions and above
Vulnerability Type(s): Denial of Service

Dubbed as TCP SACK PANIC, CVE-2019-11477 is caused by an integer overflow as the Linux networking subsystem processes TCP selective acknowledgment (SACK).

While processing TCP SACK segments, the kernel's socket buffer data structure is fragmented. To efficiently process the SACK blocks, the kernel merges multiple socket buffers into one, which potentially overflows the variable holding the number of segments.

An attacker could exploit this vulnerability by sending crafted SACK requests thereby causing a kernel panic condition. Exploitation of CVE-2019-11477 could affect the system’s availability, thus causing a denial of service. 

Worth a mention is that CVE-2019-11477 is closely related to two other vulnerabilities assigned CVE IDs: CVE-2019-11478 and CVE-2019-11479, both considered to have moderate severity.

CVE-2019-11478 is related to TCP SACK while the latter is caused by a flaw when processing Maximum Segment Size (MSS).

CVE-2019-11478 – A flaw in the Linux kernel allows attackers to send a specially-crafted sequence of SACKs requests which fragments the TCP retransmission queue.

By exploiting the fragmented queue, an attacker could cause an expensive linked-list walk for SACK requests received for the same TCP connection.

The result would be excessive system resource usage as the CPU attempts to reconstruct the list. 

CVE-2019-11479 – This vulnerability is caused by a flaw that allows hackers to send packets with low MSS value, thus leading to excessive resource consumption.
The attacker forces the kernel to segment responses into several TCP segments, each containing only 8 bytes of data.

This increases the bandwidth required to transmit the same amount of data, thus leading to excessive consumption of CPU resources and NIC processing power.

While the impact of the attack may end after the adversary stops sending traffic, there is a significant reduction in system performance that results in a DoS for some users. 

If your system is prone to these TCP SACK PANIC vulnerabilities, you need to take quick action by disabling the vulnerable component. Alternatively, you can use iptables to drop connections whose MSS size can successfully exploit the vulnerability.

The second is more effective as it mitigates the three vulnerabilities. To prevent connections with low MSS, use the following commands for traditional iptables firewalling (Note: You need to disable net.ipv4.tcp_mtu_probing for this fix to work effectively).

This drops all connection attempts whose MSS size ranges between 1 and 500.  

 A flaw caused by the Kernel’s failure to handle exceptions can lead to a denial-of-service condition.

In the CVE-2017-18017 vulnerability, the function tcpmss_mangle_packet found within net/netfilter/xt_TCPMSS.c allows remote hackers to execute a DoS attack.

Attackers can also perform unspecified actions by leveraging the existence of xt_TCPMSS in iptables actions.

The function net/netfilter/xt_TCPMSS.c plays an important role in filtering network communication in that it defines the MSS that is allowed for accepting TCP headers.

The impact of this kind of flaw could be potentially severe considering attackers can exploit the vulnerability remotely.

Here is a code snippet that can be applied to mitigate this vulnerability:

 CVE-2018-5390 is a moderately severe vulnerability in the Linux Kernel also known as SegmentSmack.

It occurs due to a flaw that exists in the way the Kernel handles specially crafted TCP packets.

Remote attackers can exploit this flaw to trigger expensive calls to tcp_prune_ofo_queue() and tcp_collapse_ofo_queue() functions by sending modified packets within active TCP sessions.

This causes CPU saturation and insufficient bandwidth to support incoming network traffic on the system, ultimately leading to a denial of service. However, for an attacker to maintain the DoS condition, they require continuous two-way sessions to an open port, which means attacks cannot be done using spoofed IP addresses. 

 Other than installing an updated or fixed Linux Kernel, you can mitigate the vulnerability by changing the default 4MB and 3MB values of net.ipv4.ipfrag_low_thresh and net.ipv4.ipfrag_high_thresh  (as well as their IPv6 counterparts) to 192kB and 256kB respectively. The result will be a significant drop in CPU saturation during the attack. 

Here is a simple script that can be used to change or lower the default settings for both IPv4 and IPv6. 

#!/bin/shif [ "x$1" == "xlow" ]; then    echo Settinig limits low:    sysctl -w net.ipv4.ipfrag_low_thresh=196608    sysctl -w net.ipv4.ipfrag_high_thresh=262144    sysctl -w net.ipv6.ip6frag_low_thresh=196608    sysctl -w net.ipv6.ip6frag_high_thresh=262144    echoelif [ "x$1" == "xdef" ]; then    echo Settinig limits default:    sysctl -w net.ipv4.ipfrag_high_thresh=4194304    sysctl -w net.ipv4.ipfrag_low_thresh=3145728    sysctl -w net.ipv6.ip6frag_high_thresh=4194304    sysctl -w net.ipv6.ip6frag_low_thresh=3145728    echofiecho Current values:sysctl net.ipv4.ipfrag_low_threshsysctl net.ipv4.ipfrag_high_threshsysctl net.ipv6.ip6frag_low_threshsysctl net.ipv6.ip6frag_high_thresh 

 The most effective way to protect yourself against Linux Kernel vulnerabilities and associated exploits is continuously scanning your repositories.

This way, it is easier to identify vulnerable open-source components in your project and provide necessary remediation on time. 

One of the best tools for the job is WhiteSource Bolt, a GitHub app that lets you scan unlimited private and public repos to detect vulnerabilities in real-time. If Bolt discovers vulnerabilities within your code, it auto-generates a new issue in the issue tracker.

It also provides a detailed report showing the vulnerability’s CVSS score as well as suggested fixes.

Here is a snapshot showing how GitHub developers use Bolt to harness the power of open source without compromising on security or agility:

Other than using Bolt, it is crucial to ensure your software product versions are always up to date. This will help you stay protected as patches and fixes are often rolled out in newer versions.