Some notes on GHOST

I haven't seen anybody compile a list of key points about the GHOST bug, so I thought I'd write up some things. I get this from reading the code, but mostly from the advisory.

Most things aren't vulnerable. Modern software uses getaddrinfo() instead. Software that uses gethostbyname() often does so in a way that can't be exploited, such as checking inet_addr() first. Therefore, even though software uses the vulnerable function doesn't mean it's actually vulnerable.

Most vulnerable things aren't exploitable. This bug is hard to exploit, only overwriting a few bytes. Most of the time, hackers will only be able to crash a program, not gain code execution.

Many exploits are local-only. It needs a domain-name of a thousand zeroes. The advisory identified many SUID programs (which give root when exploited) that accept such names on the command-line. However, it's really hard to generate such names remotely, especially for servers.

Is this another Heartbleed? Maybe, but even Heartbleed wasn't a Heartbleed. This class of bugs (Heartbleed, Shellshock, Ghost) are hard to exploit. The reason we care is because they are pervasive, in old software often going back for more than a decade, in components used by other software, and impossible to stamp out completely. With that said, hackers are far more likely to be able to exploit Shellshock and Heartbleed than Ghost. This can change quickly, though, if hackers release exploits.

Should I panic? No. This is a chronic bug that'll annoy you over the next several years, but not something terribly exploitable that you need to rush to fix right now.

Beware dynamic and statically linked libraries. Most software dynamically links glibc, which means you update it once, and it fixes all software (after a reboot). However, some software links statically, using it's own private copy of glibc instead of the system copy. This software needs to be updated individually.

There's no easy way to scan for it. You could scan for bugs like Heartbleed quickly, because they were remote facing. Since this bug isn't, it'd be hard to scan for. Right now, about the only practical thing to scan for would be Exim on port 25. Robust vulnerability scanners will often miss vulnerable systems, either because they can't log on locally, or because while they can check for dynamic glibc libraries, they can't find static ones. This makes this bug hard to eradicate -- but luckily it's not terribly exploitable (as mentioned above).

You probably have to reboot. This post is a great discussion about the real-world difficulties of patching. The message is that restarting services may not be enough -- you may need to reboot.

You can run a quick script to check for vulnerability. In the advisory, and described here, there is a quick program you can run to check if the dynamic glibc library is vulnerable. It's probably something good to add to a regression suite. Over time, you'll be re-deploying old VM images, for example, that will still be vulnerable. Therefore, you'll need to keep re-checking for this bug over and over again.

It's a Vulnerability-of-Things. A year after Heartbleed, over 200,000 web servers are still vulnerable to it. That's because they aren't traditional web-servers, but web interfaces built into devices and appliances -- "things". In the Internet-of-Things (IoT), things tend not to be patched, and will remain vulnerable for years.

This bug doesn't bypass ASLR or NX. Qualys was able to exploit this bug in Exim, despite ASLR and NX. This is a property of Exim, not GHOST. Somewhere in Exim is the ability to run an arbitrary command-line string. That's the code being executed, not native x86 code that you'd expect from the typical buffer-overflow, so NX bit doesn't apply. This vuln reaches the strings Exim produces in response, so the hacker can find where the "run" command is, thus defeating ASLR.

Some pages worth bookmarking:
http://chargen.matasano.com/chargen/2015/1/27/vulnerability-overview-ghost-cve-2015-0235.html
I'll more eventually here as I come across them.