Fix now! Unix bug puts all Linux systems at risk

[51CTO Quick Translation] Researchers have discovered a high-severity security vulnerability in the GNU C library (glibc) that could expose modern Linux servers to the risk of remote code execution attacks. API web services and popular web frameworks such as Rails, PHP, and even Python are also affected.

[[163088]]

The security vulnerability (CVE 2015-7547) is a stack-based buffer overflow in the getaddrinfo() function of the glibc DNS client resolver and has been patched. Anyone using glibc 2.9 and later (2.9 was released in May 2008) is potentially affected, which means that almost all glibc users should apply the patch as soon as possible. Red Hat Enterprise Linux 5 uses glibc 2.5 and is therefore not affected by the vulnerability; however, Red Hat Enterprise Linux 6 (using glibc 2.12), Red Hat Enterprise Linux 7 (using glibc 2.17), Debian squeeze (using glibc 2.11), Debian wheezy (using glibc 2.13), and Debian jessie (using glibc 2.19) are all affected.

"This should be taken seriously and patched for glibc ASAP. This vulnerability is very serious," Kenneth White, a security researcher and director of the Open Crypto Audit project, wrote in his tweet.

The vulnerability was originally reported by Robert Holiday of Ciena and his glibc project team in July 2015. After that, Carlos O'Donnell, chief software engineer at Red Hat, and Florian Weiner, a member of the Red Hat product security team, assessed the impact of the vulnerability and prepared a patch for it. Fermin J. Serna and Kevin Stadmeyer, researchers at Google, also independently discovered the security vulnerability mentioned in the report and launched a proof-of-concept exploit for the vulnerability.

"We are not aware of any active attacks that have exploited this vulnerability," O'Donnell said.

The getaddrinfo() function is usually used to resolve IP addresses. In this case, an attacker can exploit this vulnerability to gain control over applications and systems by connecting to a malicious DNS server. There are many possible ways to exploit this security vulnerability, including but not limited to ssh, sudo, and curl, Google researchers explained.

"Software using this function could be compromised by an attacker via a controlled domain, an attacker-controlled DNS server, or a man-in-the-middle attack," Serna and Stadmeyer wrote in the advisory.

The vulnerability is triggered when a UDP or TCP response is received from a DNS server that is too large, more than 2048 bytes, before the attacker can overwrite the stack with another response. To trigger the buffer management vulnerability, the target system must attempt a DNS search for a domain controlled by the attacker. The first response received is 2048 bytes long, which means it fills the entire buffer with no space left. Since the buffer cannot be reused, a new buffer is created. However, the vulnerability causes the old buffer to exist at the same time as the new buffer, meaning the total buffer space is 65535. The second response forces the system to retry the query. The third response contains a valid response of 2048 bytes, but there is still 63487 bytes of space available for the attack payload.

The vulnerability occurs because when the query is restarted, it refers to a buffer with the wrong capacity, O'Donnell explained. "There are other ways to trigger this buffer management vulnerability, but it requires deep control over response timing and using polling timeouts to exploit with two attacker responses (not three)," O'Donnell said.

The Red Hat researchers were also able to use the buffer overflow to control the execution of a free() call and thereby control the EIP register. Although they did not attempt to further exploit the vulnerability, the attempt demonstrated the possibility of remote control execution.

"Envelope analysis results show that an attacker can craft a well-formed DNS response with a controlled payload, thereby breaking into the DNS cache structure and gaining access to the device behind the cache," O'Donnell wrote in his glibc project group email.

The level of damage from the vulnerability depends on the system's existing buffer overflow vulnerability mitigation capabilities. Remote code execution may be "not trivial" because it requires bypassing ASLR, Google's Serna explained. Administrators and developers who cannot immediately install the glibc patch should also take temporary countermeasures to prevent potential attacks. One possible option is to limit the length of the response that the local DNS resolver can receive to 1024 bytes.

This length limit is of particular concern because systems using advanced features such as DNSSEC may need to accept UDP responses that are longer than normal. DNSSEC works with EDNSO, a client feature that notifies the server that it can accept UDP responses longer than 512 bytes. Therefore, blocking long DNS responses may break EDNSO functionality. "DNS resolution may fail or be significantly delayed," warns Johannes B. Ullrich of the SAN Association.

Administrators should ensure that all systems on the network use a specific resolver and block all outbound DNS unless it is generated by a known resolver. This limits the possibility of the vulnerability being exploited and is "a good approach," Ullrich said.

While disabling double A and AAA queries may also help mitigate this vulnerability, disabling IPv6 completely will not disable AAAA queries or prevent the vulnerability. Blocking local or intermediate resolvers for IPv6 does not prevent this vulnerability condition, as the exploit payload can still be delivered. "It is the concurrent queries that trigger the buffer management vulnerability," O'Donnell wrote.

Although patches are now available, the race is on and the outcome will depend on who moves faster - attackers or defenders. "Now that the cat is out of the bag, development teams need to quickly detect if their applications are at risk: this is difficult because glibc is deeply integrated into applications," said Patrick Carey of Black Duck Software. The patching process is also long, especially for mobile devices or other user-facing applications.

It should be pointed out that the glibc library is the standard C library used by the GNU project and is widely used in various GNU Linux and other systems including the Linux kernel. This is also the second high-risk security vulnerability exposed in the library in recent months: just last year, researchers discovered the GHOST vulnerability (CVE 2015-235) in glibc.

Original title: Patch now! Unix bug puts Linux systems at risk

[Translated by 51CTO. Please indicate the original translator and source as 51CTO.com when reprinting on partner sites]