glibc stack-based buffer overflow. What you need to know

On Tuesday, a serious vulnerability was disclosed in part of the GNU C Library. The commonly used function getaddrinfo – part of which resolves domain names to IPs – has a stack-based buffer overflow that is triggered by longer than normal DNS responses. This can lead to remote code execution.

So, just how serious is this and do you need to do anything?

Where is glibc used?

The GNU C Library provides system calls like open, malloc, printf, exit, and getaddrinfo. It’s used by most desktop and server Linux distributions. Despite being called a C library, it is also used by C++ and many other programming languages including Python, PHP and Ruby On Rails. Programs in these languages can also be vulnerable. ssh, curl, wget and many other applications will use getaddrinfo and be vulnerable.

Not everything requiring a C library uses glibc – there are alternatives. Android uses the Bionic libc (although individual apps can use whatever they choose), and many small embedded devices use uClibc. These aren’t going to be vulnerable to this issue.

Windows, OS X, FreeBSD and other OS that do not use glibc will not have problems.

Still, it does mean that a lot of systems are potentially affected.

What is the vulnerability?

By sending a longer than normal DNS response, an attacker can overflow a stack-based buffer. Under specific circumstances, this can lead to remote code execution. This means that the attacker can run code of their choosing on the machine making a DNS request.

Attacker controlled domain names, attacker controlled DNS servers, or a man-in-the-middle attack could all be triggers for this.

How long has this vulnerability been around?

This has been in glibc since 2.9 – which means since May 2008. It has only been public for days, but that doesn’t mean that it hasn’t been known about for longer.

Is it being exploited?

A proof-of-concept was released at the time of disclosure, but this only triggered a crash. Remote code execution was deliberately left out.

Within a few hours, “weaponized” versions were coming out targeting Python, where remote code execution was possible. There is no doubt that both white hats and black hats are looking for more places where it can be used.

It’s yet to be seen if this is being used against real-world systems. Rules for widely used intrusion detection systems are already available to detect any attempts.

What can be done?

Most of the common distributions of Linux had updates available immediately. These should be installed where possible. Updating glibc will generally require that some services are restarted though – the project needrestart at https://github.com/liske/needrestart can assist in choosing what needs to be restarted.

Firewalls can be configured to drop long DNS responses. It’s highly unlikely that a normal DNS request would be longer than 1024bytes. For iptables, the rules would be:

What’s still at risk?

The real concern is with embedded systems, big enough to use glibc instead of uClibc, but which won’t receive firmware updates.

Routers, DVRs, televisions, network attached storage devices – many of these don’t have firmware updates available, and if they do, they won’t be automatically applied. They are likely to stay vulnerable for years.

Further to this, embedded systems often don’t use the same protection mechanisms like ASLR, stack canaries, or non-executable stacks. These all make exploiting buffer overflows far harder, and add a lot of protection to most desktop and server Linux distributions.

Update 24/02/2016

My colleague Pedro has put together a glibc patching cheat sheet to make your life easier.