A very critical vulnerability affecting the GNU C Library (glibc) is threatening Linux servers for a remote command execution. This security bug was discovered by Qualys security researchers and will probably cause a lot of headaches to those who won’t update right away.
Where Does the Issue Come From?
This is a buffer overflow issue in glibc’s function __nss_hostname_digits_dots(), which is itself used by multiple others like gethostbyname() and gethostbyname2(). This is a critical issue as these functions are used in an enormous amount of software and server-level mechanisms. An attacker would need to send a very specific set of bytes to the function in order to trigger the bug and attempt to get command execution privileges on the victim’s server.
What Does it Affect Exactly?
So far, these applications have been proven to fall to the aforementioned attack:
- clockdiff
- procmail (through its comsat/biff feature)
- pppd
- Exim mail server (if configured with the “helo_verify_hosts” or “helo_try_verify_hosts” options)
We also have good reasons to believe PHP applications might also be affected, through its gethostbyname() function wrapper. An example of where this could be a big issue is within WordPress itself: it uses a function named wp_http_validate_url() to validate every pingback’s post URL:
…and it does so by using gethostbyname(). So an attacker could leverage this vector to insert a malicious URL that would trigger a buffer overflow bug, server-side, potentially allowing him to gain privileges on the server.
Update as Soon as Possible!
This is a very critical vulnerability and should be treated as such. If you have a dedicated server (or VPS) running Linux, you have to make sure you update it right away. We know for a fact that Centos/RHEL/Fedora 5,6,7 as vulnerable, as well as some Ubuntu versions.
As a quick test, run the following PHP code on your terminal:
php -r '$e="0";for($i=0;$i<2500;$i++){$e="0$e";} gethostbyname($e);' Segmentation fault
If you get a segmentation fault, it means your server is vulnerable. Be sure to watch for your distribution’s fix for the patch (yum update is your friend).
Isnt line 469 in the above screen shot supposed to safely check the format of the IP address before continuing. To my understand the vuln can be triggered by 1000 ints in one section of the IP address which should be circumvented by the {1-3} regex in line 469 correct??
This is if the input is an IP address, it will then match that regex and the bug won’t be triggered. If it is not an IP address though, instead it is a hostname, gethostname() will be called to acquire the IP address of the hostname given.
No, if it doesn’t match the regexp gethostbyname() get’s called. So it’s the other way around.
I see thanks for the clarification
Are you sure wordpress wp_http_validate_url case is exploitable? pase_url() and $same_host condition check doesn’t prevent from exploitation?
Just as a note, but, Zend also uses gethostbyname() in Zend_Validate_EmailAddress() as well, which is a fairly common validation class used.
The provided PHP one liner does not generate seg faults for me on servers that I know still to be vulnerable.
Same here.
I have noticed the same situation here. Hosts that are vulnerable (based on the openwall released vuln PoC) are not vulnerable when the above PHP PoC is attempted. Which may mean the gethostbyname() php function is not vulnerable and wordpress would not be an attack entry vector for this vulnerability.
Try this one instead:
php -r ‘$e=”0″;for($i=0;$i<2500;$i++){$e="0$e";gethostbyname($e); }'
This seemed to generate a crash for me as expected on a known vulnerable system
Love the segfault php oneliner 🙂
This is already patched if you use cPanel with automatic updates 😉
Am I correct in my thinking that the following check could be added so that any hostname lengths over 255 would be rejected. I believe no valid hostname could be over 255 and this would prevent a buffer overflow.
strlen($ip) > 255
How about perl?
perl -e ‘$e=”0″;for($i=0;$i<2500;$i++){$e="0$e";} gethostbyname($e);'
A clarification: this post implies a correspondence between RHEL/CentOS 5, 6, and 7 and Fedora 5, 6, and 7. There isn’t one; those numbers are very old Fedora releases which hopefully no one is running anymore. The current, supported releases are F20 and F21, and these are not vulnerable.