An overhyped GHOST

Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

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:

I find it... profoundly disappointing... that we get to learn about 0-days via PR agency leaks (or that external PR agencies get to know about 0-days before the rest of the world - hey, sounds like a juicy target). That said, the advisory makes up for it...

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:

I am more concerned that PR agencies appear to have had early access to this information than that the information leaked to the public a few hours early. When it did become public, everyone could proceed with their advisories, updates, etc. But before it did, who knows what bad bugs with access to a PR agency's database or e-mail could have been doing and for how long (I hope also just another few hours, but I really don't know). We use PGP on the linux-distros list (the issue was first brought to there on January 18), but I doubt that communication between Qualys and their PR agency, nor within the PR agency, was similarly encrypted. Perhaps they were using some Word "documents" and stuff. And even if it were encrypted, notifying a PR agency early goes beyond need-to-know from everyone else's security perspective.

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

Have their technical folks disclose to the proper technical channels instead, and do not issue a formal press release - well, or do it a few days later, referring not so much to the actual findings, but to how well the company worked with the infosec community. This would be better PR, too, at least within the smaller but highly relevant infosec community.

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.