Skip to content
Naked Security Naked Security

The GHOST vulnerability – what you need to know

The funkily-named bug of the week is GHOST. Here's how it got its name, why there's a problem, and what you can do about it...

The funkily-named bug of the week is GHOST.

Its official moniker is the less catchy CVE-2015-0235, and it’s a vulnerability caused by a buffer overflow in a system library that is used in many, if not most, Linux distributions.

A buffer overflow is where you assume, for example, that when you handle a four-byte network number written out as decimal digits, you will never get anything longer than 255.​255.​255.​255.

That takes up 15 characters, so you may decide that you’ll never need more than 15 bytes of memory.

So, if you add a spare byte for luck and allocate 16 bytes, you’re bound to have enough space.

And then, one day, a malicious user decides to see what happens if he ignores the rules, and uses a network number like, say, 1024.​10224.​102224.​1022224.

That network number is nonsense, of course, but your program might not hold out long enough to reject it.

Your code will probably crash right away, because the attacker’s 25 bytes will overflow your 16 bytes of available memory.

GHOST explained

As it happens, the GHOST vulnerability is connected with network names and numbers.

The spooky name comes from the system functions where the vulnerable code was found.

The functions are called gethostby­name() and gethostby­name2(), and they do what the names suggest.

They find the computer-friendly network number of a host (e.g. 93.​184.​216.​34) from its human-friendly name (e.g. example.com).

In other words, these functions do a DNS (domain name system) lookup for you, so your program doesn’t need to deal with the intricacies of the DNS protocol.

For example, if you ignore any error checking in your code, you might do this:

And you’d see something like this:

By the way, even if your program doesn’t directly call gethostby­name(), you may end up calling it indirectly as a side-effect of doing something, anything, involving a computer name.

For example, if your software looks up email addresses, calls home for updates, retrieves postings from online forums, plays podcasts, or any of a number of perfectly unexceptionable network-related activities, it almost certainly triggers name-to-number lookups at some point.

And if those lookups are based on data received from outside, such as a sender’s email address in received email headers, then attackers may very well get to choose what data gets passed to your Linux computer’s gethostby­name() function.

The bug

It turns out that gethostby­name() has a clever feature, where it works out whether you called it with name that is already a network number (digits-dot-digits-dot-digits-dot-digits).

In that case, it would be a waste of time to do a DNS lookup, so it doesn’t bother.

Unfortunately, the code that runs through the name to see if it’s really a network number has a buffer overflow, and if you deliberately send a super-long number laid out just right…

…poof – the GHOST strikes!

So an attacker may be able to rig up messages or network requests that crash your program; and with a bit (or, more likely, a lot) of trial and error, they might be able to trigger that crash in a way that gives them control over your computer.

That’s known as a Remote Code Execution (RCE) exploit, similar to the bug recently found in the super-secure Blackphone, though in that case it was a text message that caused the phone’s software to trip over itself.

What to do?

The good news is that this bug doesn’t exist on every computer.

It actually exists only in some versions of a software module called glibc, short for GNU C library.

In fact, most computers in the world don’t have glibc installed, because it’s not used by default on Windows, OS X, iOS or Android.

The bad news is that many, if not most, computers running Linux do use glibc, and may be at risk.

In short, therefore, if you have any Linux-based systems, including home firewalls and routers:

  • Check with your vendor, or the maker of your distribution, to see if you need a patch.
  • If you do, make plans to apply the patch as soon as you can.

Oh, and if you are a programmer, you shouldn’t really be using the gethostby­name functions anyway.

They were superseded many years ago by the much more flexible and useful function getaddr­info(), which you should use instead.

GHOST and Sophos products

Our colleagues in Support have published a handy table showing you which Sophos products include glibc, and when you can expect updates.

You will also find useful information about Sophos and GHOST on our Corporate Blog.

Image of ghost courtesy of Shutterstock.

0 Comments

Just another example that no OS is infallible. Thanks for being on top of the update. If we are running the home UTM we are vulnerable as well right? It isn’t 100% clear in the page you linked.

Thanks.

Reply

The “Home UTM” _is_ the “Sophos UTM” – same product, just the licensing is different :-)

So, yes, you will need to update it. Assuming you have the latest version, the update should appear no later than Monday 02 Feb 2015.

Reply

Interesting that this was patched almost 2 years ago, on May 21, 2013. The glibc changelog contains the ominous sentence: “Correct computation of needed size.” Still, it seems none of the big distributions noticed it is a security fix and bothered to backport it. Not even SuSE/Novell, whose employee actually made the fix to glibc…

Reply

Shows some of the dangers of a ginormous library that everyone uses and is scared to change :-)

You can spend days/weeks/months sweating over patches to convince yourself you don’t *need* them, only to find you were wrong and that if you’ve bitten the bullet right at the start, and “just made the change,” you’d be OK. Of course, you have to balance that with the chance of harming customers with changes that they didn’t particularly want and that you didn’t actually need after all…

Reply

For the sake of accuracy, I believe the actual space is 8 bytes of space – not 16 as noted in the article. Each octec in the ip address is denoted by a single byte – binary or hex notation can represent 0-255 quite nicely, then there are the single bytes for the “.” character, and finally a terminating 00 (nul) character.

Reply

As I understand it, at this point they are stored as strings (so for example, 42 is not a single byte, but two bytes, the ascii code of “4” and the ascii code of “2”). The whole point of the vulnerable function is to decide if an address (stored in a string, because it can also be a hostname) is already an IP address, therefore avoiding a DNS lookup.

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!