On August 6, 2018, security researcher Juha-Matti Tilli of Nokia Bell Labs disclosed a denial of service condition in the Linux kernel’s networking code. This condition, known as SegmentSmack or CVE-2018-5390, has the potential to exist in a large variety of devices, including production Linux servers but also other devices, such as load balancers and routers.
Vendors of potentially vulnerable products received notifications on July 23, 2018 and kernel developer David S. Miller quickly developed a patch. Although this vulnerability was introduced in version 4.9 of the Linux kernel, some Linux distributors backported the vulnerable code to earlier releases since the code contains notable performance enhancements.
A set of specially crafted TCP packets to any open port can force the kernel to call two CPU-intensive functions, tcp_collapse_ofo_queue() and tcp_prune_ofo_queue(), forcing resource exhaustion. An attacker can stall an affected device with as few as 2,000 packets per second. Researchers at the Linux vendor Red Hat were able to completely saturate four CPU cores using four streams on a vulnerable system.
The patch limits the amount of CPU usage this condition can utilize, rendering the attack ineffective.
To exploit the vulnerability, an attacker needs inbound TCP access to the server. The vulnerability does not allow remote code execution. As of the publication of this SPOT report, there is no proof of concept for the exploit available.
A malicious attacker can use this vulnerability to send a small number of specially crafted packets to a server to increase CPU utilization to 100% and cause a denial of service condition by limiting the amount of CPU resources available for legitimate tasks.
Linux distributions confirmed to to be vulnerable to SegmentSmack include:
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7
- Oracle Enterprise Linux 7
- SuSE Linux Enterprise Server 15
- Ubuntu 18.04 LTS
- Amazon Linux AMI version 2017.03
- Amazon Linux AMI version 2017.09
- Amazon Linux AMI version 2018.03
This is not an exhaustive list. Many Linux distributors backported the vulnerable code to older kernel versions. Systems can also be upgraded to newer kernels in the field by an experienced system administrator.
What You Should Do
Scan your network for CVE-2018-5390 using a reputable vulnerability scanner to build an inventory of affected systems, starting with your cloud-based infrastructure and your DMZ. Alternatively, you can sign into systems and issue the command uname -a to capture the kernel version. However, this check is not fully reliable as some Linux vendors backported kernel 4.9 networking code to earlier kernels.
When scanning your DMZ and internal network, do not limit your scope simply to name-brand Linux systems, as this vulnerability can affect embedded systems and appliances as well, such as F5 load balancers. Use authenticated scans if at all possible to increase accuracy. Since this vulnerability exists in very specific Linux kernel versions, authentication makes it much easier to correctly identify vulnerable systems.
Patch affected systems as soon as possible, especially publicly facing systems. Retain the old kernel long enough to verify the system still functions, then remove the old kernel to keep someone from rebooting the system with the old kernel and reintroducing the vulnerability. Kernel updates normally require a reboot to fully take effect, so this patch will require a small amount of downtime.
Since this attack involves specially crafted packets that can be sent to legitimate ports, there is no practical way to mitigate this attack in bulk using firewalls or other common compensating controls. However, the nature of the vulnerability prevents an attacker from using a spoofed IP address. This means a system under attack could be protected temporarily on a case-by-case basis with a local iptables rule blocking traffic from the source of the attack.
Issuing this command on an affected system will block traffic from a specific IP address:
iptables -A INPUT -s 192.168.1.1 -j DROP
Substitute the public IP address the attack is coming from for 192.168.1.1.
To remove the rule, either reboot the system or issue the following sequence of commands:
This prints the local firewall rules. Identify the rule line blocking the traffic you want to delete, then issue this command:
iptables -D INPUT 1
- Dave Farquhar – vSOC Program Manager