The funkily-named bug of the week is GHOST.
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.
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 gethostbyname() and gethostbyname2(), 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 gethostbyname(), 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 gethostbyname() function.
It turns out that gethostbyname() 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.
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:
[if !supportLists]· [endif]Check with your vendor, or the maker of your distribution, to see if you need a patch.
[if !supportLists]· [endif]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 gethostbyname functions anyway.
They were superseded many years ago by the much more flexible and useful function getaddrinfo(), which you should use instead.