After Ghost in January 2015, a new vulnerability has been found on the Glibc, affecting Linux servers! Let us pause for a moment and understand how it works.
What is the Glibc ?
When a request is sent to a program, the program uses one or several functions to achieve the requested result. These functions are stored in libraries, some of which contain basic functions. The latter are shared by many programs: it is the case of the Libc.
The Libc used in Linux systems was created by the GNU oragnization, which called it Glibc. The bug recently discovered by Google and Red Hat experts is located in this library.
For further explanations about the Glibc, check out our article about the Ghost vulnerability.
The security flaw: a buffer overflow in the DNS lookup
The bug can be found in all Glibc versions from 2.9 on. It is a buffer overflow (what is a buffer overflow) in the DNS (Domain Name Server) lookup of a machine, allowing remote code execution. Explanation:
When a Internet user wishes to visit a website whose domain name he or she knows, for instance www.nbs-system.com, its machine will query a DNS server in order to get the IP address of the website. It will then be able to connect directly to the IP adress to access the website.
By default, machines keep a space of 2048 bytes to store the DNS server’s answers. An IP address is 4 bytes long, which means that up to 512 addresses can be stored in the answer. Even if some websites register more than one IP address, the answer can thus be contained without any problem in this memory slot.
If an answer is longer than 2048 bytes, then the machine will create a second memory slot dedicated to the reception of the answer’s surplus amount. There thus seems to be no risk of a buffer overflow.
However, under certain conditions, the machine will not use this second storage space. If the answer exceeds the limit, then the 2048 first bytes will be stored on the first slot, and the following bytes will be stored right after it. They will erase and replace the code that was written before: that is the buffer overflow.
In order to be able to exploit this web security flaw, a hacker has to fulfill one of the following conditions:
- Control a DNS server
- Place himself as a “man-in-the-middle” between the user and a DNS server, to rewrite on the fly its responses before the user receives them
- Have a website and handle one’s own DNS server (in that case, the user’s request and the server’s response have to go through many intermediary servers, making the success of the attack less likely).
Once one of these conditions is fulfilled, the hacker is free to write responses as such: “2048 bytes (IP addresses for instance)” + “code lines”. The goal is for the second part, containing code lines, to be written directly next to the reserved memory space, as a replacement of the code already on the machine. It is the foundation of what will allow the hacker to remotely execute code.
But for that, the machine has to not write the response’s surplus into the second memory space! The hacker thus has to go through a few more actions. Google’s experts did not secify which actions, in order not to ease the vulnerability’s exploitation. They did, however, mention vectors such as sudo, ssh or curl.
An extra risk can also be noted: we talked until now about a user’s machine. However, the exploit of this flaw can be done on a larger scale. If a company uses an intermediary DNS server, passing on to an Internet Service Provider’s DNS server, this server can be hacked. The answers being then sent to all the internal network’s machine, they also fall under the hacker’s control: he killed many birds with one stone.
If a pirate handles his own DNS server for a website, he can act on an even larger scale: by sending its answer through intermediary servers, he increases the risk of his attack being blocked, but if it works, the answer is very likely to be cached, and thus to be sent to all machines trying to connect to his website through the intermediary server. Coupled with a social engineering operation, such an attack can rapidly grow in size.
Conclusion: the attack can have huge consequences, and its exploit is not really technically complicated. The obstacles here are the conditions the pirate has to fulfill in order to succeed.
There is only one solution : apply the patch.
Glibc/DNS security: to go further
If you wish to know more about the vulnerability, read the following articles:
Source : Emile Heitor