GLIBC GHOST Vulnerability and Do We Need to Reboot

A new remote zero-day security vulnerability has been discovered in the glibc under CVE-2015-0235. This vulnerability allows attackers to remotely access some vulnerable Linux-based systems without the use of compromised passwords or other user credentials. Once in the system, attackers could leverage other vulnerabilities to escalate privileges until they gain root access.

Addressing the Issue

A glibc patch has been released to address this issue and we have already updated public and private hosting servers. There is quite a buzz around the question if a server should be rebooted after the patch. The great guys from CloudLinux have already answered this question in a quite informative and straight forward way in their blog post.

For informational purposes, we decided to share their conclusion:

First of all – no all services that use glibc need to be restarted. Only services that use gethostbyname. That function is used to resolve internet host name to IP address. Now, to exploit this function, attacker needs to be able to able to feed 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 such bug. So, no need to restart it.

So, what can be potentially exploitable, and should be restart:

1. Exim: only when it is configured to resolve the remote host name. 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 restart is once again – cheap.
6. PostgreSQL – we don’t really know, so restart it just in case.
7. OpenSSH – it is 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, rsyslogd, mysql/mariadb – are all considered safe – but should be easy to restart if you feel like it.

We already took the necessary actions to address the issue so you can rest assured that your hosting accounts and server is safe.

In Need of Assistance?

Still, if you are experiencing any difficulties, or you wish to make sure that everything is handled by an expert support team, you can post a new ticket and request help from our technical support team. The service is available for all existing clients, completely free of charge. If you are not a FastComet customer, you can review our Hosting plans, for more detailed information on what we offer.