GLIBC GHOST – How to Deal with it?

A critical vulnerability in the glibc library has been announced by Red Hat Product Security, assigned as CVE-2015-0235, and is commonly called as ‘GHOST’.

What is a GHOST? 

A buffer-overflow bug, GHOST affects the gethostbyname() and gethostbyname2() function calls in the glibc library. A remote attacker can make an application call to either of these functions to execute arbitrary code with the permissions of the user running the application.

Impact of GHOST

The gethostbyname() function call is used for resolving DNS which is a very common event. This vulnerability can be exploited by an attacker by triggering a buffer overflow by offering an invalid hostname argument to an application that performs a DNS resolution.

There’s a lot of confusion about the need to reboot due to GLIBC GHOST bug. Is it really essential to restart ‘vulnerable services’ or reboot the server?

No doubt,  you have to restart vulnerable services, yet there is no need to restart the whole server – if you know what it is running (Note: – In shared hosting – we actually do).

First of all – All services that use glibc don’t need to restart. Only services that use gethostbyname. That function is used to resolve the internet hostname to an IP address.

To exploit this function, the attacker needs to be able to feed a specially crafted ‘host name’ to the service. And service needs to process it without validating it first.

That is not a common condition. For example /sbin/init, while using glibc will not be exploitable at all using the such bug. So, no need to restart it.

So, what can be potentially exploitable, and restarted:

1. Exim: only when configured to resolve the remote hostname. Restart it.
2. Apache – apache itself is not exploitable, but some modules might be checking remote hosts – so, why not restart it. You should also restart PHP FPM, mod_lsapi daemon if you are running it in self_starter mode.  Restart it just in case
3. LiteSpeed – restart it just in case.
4. Nginx – it is not vulnerable, and most common configurations I have seen on shared hosts will not be vulnerable as well – but given how cheap it is to restart it — restart it.
5. cPanel (or your favorite brand of the control panel) – yes, worth it, including cpHulkd. They might be not vulnerable at all – but with closed-source software — you never know, and such a restart is once again – cheap.
6. PostgreSQL – we don’t really know, so restart it just in case.
7. OpenSSH — it considered safe, but if you want to be really safe — restarting OpenSSH doesn’t require any server downtime.
8. Postfix/Sendmail – most likely it is safe, but same as with OpenSSH — restarting it doesn’t take much.

Proftpd, pure-ftpd,vsftpd,xinetd, tcp_wrappers, Syslog, MySQL/MariaDB –> are all considered safe – but should be easy to restart if you feel like it.

Why so several people confused with rebooting the server?

Unlike shared hosting servers — generic servers run various software — and it is really hard to predict which software is vulnerable and which is not. So, for them – the best way to go is to reboot.

In shared hosting — not as important.

Resolution

In order to avoid the possibility of an exploit –

1. Update the glibc and nscd packages on your system using the packages related to the following errata:
   

   Red Hat Enterprise Linux Server 5: RHSA-2015:0090

   Red Hat Enterprise Linux Server (v. 6): RHSA-2015:0092

   Red Hat Enterprise Linux Server (v. 7): RHSA-2015:0092

   Red Hat Enterprise Linux Desktop 5: RHSA-2015:0090

   Red Hat Enterprise Linux Desktop 6: RHSA-2015:0092

   Red Hat Enterprise Linux Desktop 7: RHSA-2015:0092

   Red Hat Enterprise Linux HPC Node 6: RHSA-2015:0092

   Red Hat Enterprise Linux HPC Node 7: RHSA-2015:0092

   Red Hat Enterprise Linux Workstation 6: RHSA-2015:0092

   Red Hat Enterprise Linux Workstation 7: RHSA-2015:0092

   Red Hat Enterprise Linux Server EUS (v. 6.6): RHSA-2015:0092

   Red Hat Enterprise Linux Server EUS (v. 6.5): RHSA-2015:0099

   Red Hat Enterprise Linux Server EUS (v. 6.4): RHSA-2015:0099

   Red Hat Enterprise Linux Server EUS (v. 5.9): RHSA-2015:0099

   Red Hat Enterprise Linux ELS (v. 4): RHSA-2015:0101

 2. Now reboot the system or restart all affected services –

This vulnerability affects several applications on the system, therefore, the safest and recommended way to assure every application uses the updated glibc packages is to restart the system.

But if you aren’t able to restart the entire system after the update, run the following command to list all the running processes though you are using the old [in-built] version of glibc on your system.

lsof +c0 -d DEL | awk 'NR==1 || /libc-/ {print $2,$1,$4,$NF}' | column -t

When the list gets generated, identify the public-facing services and restart them. Though might be a temporary solution, it isn’t supported by Red Hat and if any problem arises, you asked to reboot the system prior to the beginning of any troubleshooting.