An overhyped GHOST

While the GHOST glibc vulnerability is serious, it also seems to be fairly hard to exploit—and has been seriously overhyped. Part of the hype may stem from Qualys, which found the bug, engaging a public relations (PR) firm to publicize the bug and Qualys's role in finding it. But someone at the PR company botched the coordinated release, so the information leaked out hours before the planned release time. That is troubling on (at least) two levels: that PR is even a part of security disclosure and that PR firms sometimes get advance notice of zero-day flaws.

The actual GHOST vulnerability is a bog-standard buffer overflow in the GNU C library (glibc) implementation of gethostbyname() and gethostbyname2() (and others in that family). As described by Qualys in a detailed advisory, the length of a buffer is miscalculated in the __nss_hostname_digits_dots() function so it is short by the length of one pointer (four or eight bytes, depending on the architecture). That means the buffer involved can be overflowed by four or eight bytes. The buffer resides on the heap, so an overflow writes into the data structure maintained by malloc() for the free chunk of memory that is contiguous to the buffer.

Messing up the malloc() data structure doesn't directly lead to an exploit, of course, but Qualys was able to exploit the Exim mail server to run arbitrary code. It is instructive to note that Qualys was able to cause the buffer overflow in a few other programs (e.g. procmail, clockdiff), but was unable to do so for a wide variety of other network-facing tools (e.g. Apache httpd, MySQL, Postfix, Samba) as noted in a followup to the advisory.

It is not just server code that is affected, however. As Stephane Chazelas pointed out on the oss-security mailing list, some web browsers and email clients call the gethostbyname() family. But, as Qualys explained, there is a pretty long list of qualifications that have to be met before a string passed to those functions can overflow the buffer. It must consist of only digits ("0"-"9") and dots ("."), must be long enough, and, probably the most strict requirement, must pass muster with inet_aton(). Several uses of gethostbyname() were eliminated from consideration by Qualys because the function was only called if inet_aton() failed.

The bug was fixed in glibc in May 2013, but it was not recognized as a security problem at the time. The bug report mentions an incorrect error return in the title; the description does have some information about buffer sizes, but there is no crash reported, which might have caused more scrutiny for security implications. In any case, the fix made it into the glibc 2.18 release in August 2013. Since then, most of the rapidly updating distributions (e.g. Fedora, openSUSE, Ubuntu, Debian testing) have picked up the newer glibc version. Because the fix was not identified as a security update, though, enterprise and other more stable distributions (e.g. RHEL, Ubuntu 12.04 LTS, Debian 7.0 "wheezy") have not been updated—until now.

Interestingly, the bug was also found and fixed in ChromeOS in April 2014. Even though it was recognized as a buffer overflow with potential security impacts, no alarm was raised at that time. The fact that the bug had already been fixed and released in glibc may have contributed to that.

Eventually, Qualys spotted the flaw, alerted the linux-distros security mailing list, and started coordinating a date and time to release the information in conjunction with fixes from the distributions. Somewhere in there, a logo was designed and a PR firm (AL'X Communication) was engaged to publicize the bug. A few hours before the designated release time, a French version of the press release was posted to a French system-administration mailing list. Once that was noticed, Qualys went ahead and put out its advisory.

Finding out about a problem by way of a PR leak seems sub-optimal, as Michał Zalewski noted:

Qualys's advisory is excellent, as Zalewski said. Whether that makes up for turning over information on a zero-day flaw in a widely used package to a PR firm will be determined by the eye of the beholder. Alexander Peslyak (aka Solar Designer) was also concerned about the PR agency's involvement:

Peslyak went on to suggest that security firms take a different strategy when trying to publicize their role in finding bugs.

In the wake of Heartbleed and other vulnerabilities (which seem to come with logos and web sites these days), it seems hard to believe that security firms will heed Peslyak's advice. For good or ill, the days of vulnerability disclosure by press release (and soon, presumably, press conferences) is upon us. That is most certainly going to lead to bugs that are hyped beyond their actual impact, as was done here.

As Brad Spengler pointed out in an LWN comment, even the Exim exploit requires a non-default configuration, so the number of affected systems is probably fairly small. Absent finding other server or client programs that are vulnerable (and there are probably a few), there may not be that many hosts out there that are truly vulnerable. In addition, the gethostbyname*() functions are obsolete at this point, so up-to-date programs are using getaddrinfo() which doesn't suffer from this problem.

With all that said, GHOST is still a vulnerability worth patching. There may be other subtleties that haven't yet surfaced. But it does seem that both Qualys and some parts of the technical media have overblown this vulnerability greatly. As with everything in security, there is a tradeoff here. Had GHOST been a more severe and widespread issue, raising the "panic" flag might have been sensible (as with Heartbleed). Panicking over this GHOST, though, seems something of a stretch.