Last updated at Fri, 29 Sep 2017 14:33:09 GMT

If you've been involved in patch frenzies for any reasonable amount of time, you might remember last year's hullabaloo around GHOST, a vulnerability in glibc's gethostbyname() function. Well, another year, another resolver bug.

gethostbyname(), meet getaddrinfo()

This time, it's an exploitable vulnerability in glibc's getaddrinfo(). Like GHOST, this will affect loads and loads of Linux client and server applications, and like GHOST, it's pretty difficult to "scan the Internet" for it, since it's a bug in shared library code. Google reports they have a working private exploit, and I know those rascals on the Metasploit team have been poking at the vulnerability today, so do yourself a favor and patch and reboot your affected systems as soon as practical.

The Long Tail of IoT

Unfortunately, as the Ars Technica article points out, there are certainly loads and loads of IoT devices out in the world that aren't likely to see a patch any time soon. So, for all those devices you can't reasonably patch, your network administrator could take a look at the mitigations published by RedHat, and consider the impact of limiting the actual on-the-wire size of DNS replies in your environment. While it's may be a heavy-handed strategy, it will buy you time to ferret out all those IoT devices that people have squirrelled away on your network.

Take A Breath

Finally, as with GHOST, there is a valid reason to be concerned, but we don't think this is the end-of-the-internet-as-we-know-it.

The bad news is that an exploit against at least one vector is known to exist, and the impact can be nasty if an attacker can segfault your processes with a malformed DNS response, and worse if they're clever and lucky enough to pop a shell. Plenty of legacy systems will be affected. So that all sounds pretty bad, yes?

But, ultimately, this bug is far more difficult to exploit than many. It's difficult to target (by both bad guys and good guys), and the attacks tend to require client interaction. As for those legacy systems? They tend to have, if not bigger problems, adjacent and better understood problems, like Shellshock and Heartbleed.

The bottom line is that you should patch (as with any CVE-classified bug), but I wouldn't expect the Internet to come crashing down over this.

Are Rapid7's Products Impacted?

We're still investigating which of Rapid7's products are impacted, and will update customers as we know more.  So far, we can confirm that both physical and virtual Nexpose appliances are affected and operating systems for them will need to be updated. Nexpose hosted engines are also affected and are being patched as I type. In both cases, we will reach out to any affected customers to advise on any action that needs to be taken by them.

Nexpose Coverage

Meanwhile, Nexpose picked up the glibc patch update earlier today, and it's going through analysis now; we can expect a check for Nexpose customers shortly, as we're targeting tomorrow's regular release for that. Armed with a Nexpose check, you can get a decent idea of what your threat exposure is to this bug-that-shall-not-be-branded, on the chance that it really does take off in the coming days.