Glibc Vulnerability - CVE-2015-7547

To understand how glibc vulnerability works, you have to understand how Linux works. The Linux operating system relies on its kernel which handles process control, networking, access to hardware and the file system. This design depends on the C Library to carry out many basic operating systems tasks. These system calls are a programmatic way in which a computer program makes requests for services from the kernel of the operating system. This may include hardware related services like accessing the hard drive or utilizing the network interface. It also performs the creations and execution of new processes and communication that require kernel services like scheduling tasks. A few examples of the C library that issues system calls and other basic functions are Printf, or exit.

Below is a diagram of how the applications utilize the C Library to make system calls.

how an application utilizes the C Library to make system calls

This vulnerability in the DNS resolver will allow an exploit to potentially perform a buffer overflow. The only releases that are vulnerable was introduced in 2008 v2.9 through v2.22. For Red Hat/CentOS, versions 6 and 7 are affected. The Google Security Team and Red Hat discovered that the eglibc host name resolver function, getaddrinfo, when processing AF_UNSPEC queries (for dual A/AAAA lookups). They found that it could mismanage the internal buffers, leading to a stack-based buffer overflow and arbitrary code execution. This vulnerability affects most applications which perform host name resolution using getaddrinfo, including system services.

This is one of the potential examples of how a malicious actor may exploit this vulnerability.

Step 1. Have the vulnerable system attempt a DNS resolution to a domain that the attacker controls
Step 2. The first response is 2048 bytes filling the allocation buffer entirely
Step 3. Next response will be flawed which will force the libc to retry the query continuously
Step 4. Send a 3rd response with another 2048 bytes and 63487 additional bytes for an attack payload

There are several other ways to trigger the buffer overflow that require more of a response time and timeouts to conduct the exploiting with just two responses versus the three we used in the above example. The vulnerability happens when the send_dg is retried it restarts the query, but the second time the answer buffer directs you to the allocated buffer but with the wrong size. Again, this is one of many ways to attempt the overflow and payload injection. This could also be potentially used with TCP which requires a three hand handshake connection. There are several questions, with the control, that the c library offers. We will start to see a move of ransomware use to a Linux platform via direct hard drive access.

For a detailed technical report on CVE-2015-7547, from Carlos O’Donell at Red Hat, click on the link below. 
[PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based ...

How to fix and patch for CVE-2015-7547
GeekStuff has a great guide to walk you through the process of patching the system.

About the Author

Stephen Coty - Chief Security Evangelist at Alert Logic

Stephen Coty

Stephen Coty originally joined Alert Logic as the head of the Threat Research team, where he led the effort to build threat content and deliver threat intelligence. He later became the Chief Security Evangelist for the company. Prior to joining Alert Logic, Coty was the Manager of Cyber Security for Rackspace Hosting, and has held IT positions at multiple companies, including Wells Fargo Bank, Applied Materials, Stanford Medical Center and The Netigy Corporation. He has been in the Information Technology field since 1993. Research has been his primary focus since 2007.

@StephenCoty | More Posts by Stephen Coty