Is the Ghost bug still haunting your servers?

Forgotten vulnerabilities can come back to haunt you. It’s just too easy to assume that you’ve patched or upgraded thoroughly enough so that a dangerous, widely reported vulnerability is no longer dangerous.

But, in reality, your security team may have missed a critical patch – or you might have unknowingly acquired an unpatched workload. For example, by purchasing additional technology solutions or because your organization acquired or merged with another.

That is why it is worth double-checking that your workloads are thoroughly patched against the most critical vulnerabilities. One of these is the Ghost bug, a vulnerability that affects GNU C Library release 2.2. The GNU C Library is a library of open-source code that powers countless applications and services.

Ghost isn’t a bug you can risk being careless about: Ghost received the maximum CVSS score of 10 which indicated that it is extremely critical.

In this article, we explain how the Ghost vulnerability works, outline why Ghost can still pose a danger to your operations, and explain what you can do to check whether you have any unpatched GNU C Libraries in your systems.

Content:

1. What is the Ghost bug – also known as the glibc vulnerability?
2. How to patch your servers against CVE-2015-0235
3. Check if you are vulnerable to Ghost with uChecker
4. Regular patching is key – for Ghost, and for future vulnerabilities

What is the Ghost bug – also known as the glibc vulnerability?

This glibc vulnerability was discovered by researchers at security vendor Qualys in January 2015 and was assigned CVE-2015-0235 at the time.

Qualys found that the __nss_hostname_digits_dots() function of the GNU C Library had a buffer overflow vulnerability that can be triggered not just by local users, but by remote users too. Remote attackers are able to use this buffer overflow flaw to execute arbitrary code on your server using the permissions of the user running the application that’s deploying glibc.

The researchers published a sample analysis showing how a system can be breached using the Exim mail application as an example, but any Linux application that uses the gethostbyname() or gethostbyname2() function is vulnerable as these provides routes to exploit the __nss_hostname_digits_dots() vulnerability.

With this vulnerability, a remote attacker can gain complete control of your system without you even knowing about it. It’s also worth noting that Ghost is an easy exploit to implement. In other words, attackers can exploit a vulnerable system with relatively little effort, which is one reason why Ghost scored so high on the CVSS index – scoring the maximum of ten, meaning it’s a critical vulnerability.

It is widespread too, with most Linux systems affected by the vulnerability. You can find a list of the affected products here.

How to patch your servers against CVE-2015-0235

One interesting point to note is that Ghost was included in glibc-2.2, which was released in 2000. In a later release, glibc-2.18, the vulnerability was fixed as part of an update of the GNU C Library.

However, this fix was due to a routine update to the libraries and was therefore not “marked” as a security release. For that reason, vendors did not automatically release an update for glibc-2.2 until the vulnerability was discovered at a later stage.

While you may have upgraded your software in the meantime, and by consequence upgraded to a new and unaffected version of the GNU C Library, it may also be the case that you’re still relying on release 2.2.

Any system that still depends on the vulnerable version of the library needs to get patched. Given the severity of the vulnerability, patches were released by major vendors, and fixing the vulnerability is as simple as patching the Linux distribution you’re using.

You can also manually update the glibc library using the command line in your operating system – the latest libraries are here, but of course, always remember to reboot your server after you have installed the update.

Of course, if you are currently using KernelCare Enterprise by TuxCare and deploy its add-on LibraryCare, you have nothing to worry about. The Ghost bug and many other vulnerabilities are already patched on your systems.

However, if you find out that one more of your systems needs to be patched, you can easily register it for patching in the TuxCare ePortal, and you can be assured it’ll be patched in memory without rebooting.

Check if you are vulnerable to Ghost with UChecker

When a vulnerability is as dangerous as Ghost it’s worth double-checking that your workload is thoroughly patched against that vulnerability – even if a vulnerability is a few years old.

While a qualified security team will always patch dangerous vulnerabilities promptly, human error can creep in – and sometimes unpatched workloads can sneak in due to corporate acquisitions or because you introduced a new technology solution that happens to contain an unpatched library.

Thankfully, there’s an easy way to check whether you need patching to protect your servers against Ghost.

At TuxCare, we’ve developed a free-to-use tool that’s licensed under GNU GPL 2. It’s called uChecker, and it automatically scans your system for unpatched libraries – including glibc. Installing uChecker is simple. Just run this command:

curl -s -L https://kernelcare.com/uchecker | python

When you run uChecker you’ll get a complete report of all libraries that require patching. This includes libraries stored on disk, as well as libraries currently loaded in memory.

As a matter of security, you should thoroughly check code you download from the internet before running it in your systems. The command above can, and should, be separated into two – one to download the code which you would check, and then another to actually run it. Shown above is just a convenient way of running uChecker, not the best security practice.

Regular patching is key – for Ghost, and for future vulnerabilities

The Ghost bug is still out there and there is a chance it may be haunting your systems and creating a backdoor for attackers. If you use an automated, rebootless library patching service there will be nothing for you to worry about as your GNU C libraries will be bang up to date.

Unsure if you’ve patched as comprehensively as you should have? Why not try out uChecker – it’s free to use and will quickly alert you if you’re still vulnerable to the dangerous Ghost bug.

The bottom line is that regular patching will keep your systems safe year in, year out – including against the most dangerous vulnerabilities. There are always new CVEs being published, and it is crucial to keep an eye on CVEs and to check if your systems are in danger.

Glibc alone, for example, registered five vulnerabilities through to the middle of July 2021, when this article was written. That’s one new vulnerability every month, in glibc alone.

Of course, Ghost has been and still is (for those who haven’t patched yet) one of the most dangerous library vulnerabilities. But who says there won’t be another vulnerability as dangerous as the old “Ghost”?

What do you think would be a good way to manage a new, dangerous vulnerability? Do you think your team is ready for a challenge as big as CVE-2015-0235? Will you and your team be able to discover vulnerable systems and patch these immediately if the worst happens?

These are some points that you should think about – because one thing we can be certain about is that the discovery of another dangerous vulnerability is just around the corner.