A Linux Suffering from systemd(System and Service Manager) vulnerability that leads to performing a Denial of Service in many Linux based Distributions.
Attacker Sending a DNS query to a DNS server by having a Vulnerable system eventually this vulnerability will exploit the Target Linux distribution systems.
systemd is an init system used in Linux distributions to bootstrap the userspace. Subsequently to booting, it is used to manage system processes.
Later, a specific crafted query will return to the DNS server which causes the systemd to perform an infinite loop that pins the system’s CPU usage to 100%.
Also Read: Multiple Denial of service Vulnerabilities Discovered in Linux kernel USB Subsystem
An attacker using phishing and social engineering attack to visit users system to Domain controller and later user will redirect to query the DNS.
Researchers created a custom DNS server which would send back maliciously formed replies to test this vulnerability.
Packet capture of specially crafted DNS reply
Here a reply contains an NSEC record that is Designed to trigger the vulnerability.
Every time system running systemd uses it for DNS resolution, it will receive this specially crafted DNS packet, and the CPU utilization would hit 100%.
Maximized CPU utilization
According to Trend Micro, New functions have been added to DNS over time, both to add new features and make it more secure. One of the new types of resource records added in DNS Security Extensions (DNSSEC), as defined in RFC 4034, was the NSEC (Next Secure) record.
The vulnerability lies in the processing of the bits representing pseudo-types in the NSEC bitmap
Patch this Vulnerability in systemd is the most effective way to fix this issue.Trend Micro reported to concern vendors via the Zero-Day Initiative (ZDI) in the same month.No attacks against this vulnerability are known to be in the wild yet.
Mitigation for Denial of Service in Linux
Trend Micro Provide following mitigation technique for this vulnerability.
As we noted earlier, fixes to this vulnerability have been released. We recommend applying these to systems at risk as soon as possible.
System administrators may also opt to block potentially malicious packets manually. Incoming DNS responses should be checked to see if they contain resource records as specified in section 4 of RFC 4034.
Monitor incoming DNS response traffic and detect if the DNS RRs in the answer section contains DNS and record of types as specified in the RFC 4034 section 4, which defines NSEC RRs. If the attached bitmap is processed and contains pseudo-types, it should be blocked
