GHOST gethostbyname() heap overflow in glibc (CVE-2015-0235)

A heap-based buffer overflow vulnerability in glibc (CVE-2015-0235) was announced this week.

It seems as though all new vulnerabilities need to have catchy marketing names so this one was dubbed "GHOST" which was derived from the vulnerable glibc function name - "GetHOSTbyname()".

Vulnerability Notes

Here are the key points thus far:

• The vulnerability affects all versions of glibc from glibc-2.17 and lower
• The bug was patched in glibc-2.18 in May 2013, but was not marked as a security bug so the fix did not make it into many common Linux distributions like SUSE and Ubuntu until much later.
• To our knowledge, this is not currently being exploited in the wild
• Qualys has not released any PoC code but they plan to release a Metasploit module in the near future.
• Qualys was able to remotely exploit a mail server running Exim mail software but it's unclear what other software might be vulnerable. (They are working on a metapsloit module specifically for the Exim exploit)

Regarding other Linux server software Qualys wrote:

"to the best of our knowledge, the buffer overflow cannot be triggered in any of [these]:

apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql,

nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd,

pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers,

vsftpd, xinetd."

Wordpress XML-RPC Pingback Vector

It has been speculated that the XML-RPC pingback functionality in Wordpress installs may be vulnerable to remote exploitation. We decided to run some tests to see if it is in fact vulnerable. We previously did a blog post outlining how the Wordpress XML-RPC "pingback" functionality could be abused by attackers to force unsuspecting websites into participating in DDoS attacks. To summarize, in that attack, the attacker sends an XML request to the "/xmlrpc.php" script:

The YELLOW highlighted data is a WordPress "Patsy Proxy" site while the ORANGE highlighted data is the DDoS target/victim website. In this scenario, the XML-RPC "pingback" code in PHP is using the gethostbyname() function call on the ORANGE highlighted data so that it can resolve it to an IP address for the remote request it will send. This is the exploit vector we chose to focus on for GHOST testing.

Modifying Input for GHOST Vulnerability Testing

Instead of sending a normal sized URL in the XML pingback.ping method body, we need to send a large one. Here is a Ruby PoC script:

The script takes command line arguments for the size of payload that you want to send. During our testing in SpiderLabs Research, we identified different size ranges that worked on different platform/versions of glibc, php and wordpress. After sending the attack payload, we have seen the HTTP process responds with the following:

• 500 HTTP Response Status code with php-cgi
• No HTTP Response with mod_php

There are errors in the Apache error_log file when the process crashes:

This PoC allows users to remotely verify if a target web server is vulnerable to the CVE however it does not demonstrate exploitability. Here is the glibc and php version information for the two systems we used during this test:

Recommendations

Install glibc Patches

Example for Ubuntu Linux Distributions:

sudo apt-get clean
sudo apt-get update
sudo apt-get upgrade

And don't forget to reboot!

Disable XML-RPC

It is possible to disable the XML-RPC process altogether if you do not want to use it. There are even plugins that will disable it.

Disable Pingback Requests

You may also disable the pingback feature by adding the following to your functions.php file:

WAF Protections

By using a WAF, you can identify initial pingback XML requests on your Wordpress site and look for attacks. The Trustwave WAF has a profiling and learning engine called "Adaption" that is able to identify these types of anomalies vs. normal user traffic. We have also added rules to our commercial SpiderLabs ModSecurity rules package to identify this specific PoC attack vector.

Monitor Your Logs

When attackers are attempting to exploit this vulnerability against your web servers, there will most likely be error messages (segmentation faults, etc...) that will indicate a problem. Organizations should be vigilant in monitoring their logs and following up on an anomalous errors.

Acknowledgments

I would like to thank my fellow SpiderLabs Research colleagues who helped with testing and the content of this blog post:

• Robert Rowley
• Christophe De La Fuente
• Chaim Sanders
• Felipe Costa
• Jonathan Claudius
• Karl Sigler