We disagree on that, especially when they're widespread (and you don't get much more widespread than glibc) and "drop everything and patch"-level severity.
Having a shorthand to refer to the bug makes it more easy (and therefore more likely) that it will get referenced and discussed.
Having a shorthand makes it a lot easier for people to freak out and panic unnecessarily, too. "Heartbleed" was big enough to warrant a world-wide freakout, but this is a remote buffer overflow with many requirements for success.
--[ 3 - Mitigating factors ]--------------------------------------------------
The impact of this bug is reduced significantly by the following reasons:
- A patch already exists (since May 21, 2013), and has been applied and
tested since glibc-2.18, released on August 12, 2013:
- The gethostbyname*() functions are obsolete; with the advent of IPv6,
recent applications use getaddrinfo() instead.
- Many programs, especially SUID binaries reachable locally, use
gethostbyname() if, and only if, a preliminary call to inet_aton()
fails. However, a subsequent call must also succeed (the "inet-aton"
requirement) in order to reach the overflow: this is impossible, and
such programs are therefore safe.
- Most of the other programs, especially servers reachable remotely, use
gethostbyname() to perform forward-confirmed reverse DNS (FCrDNS, also
known as full-circle reverse DNS) checks. These programs are generally
safe, because the hostname passed to gethostbyname() has normally been
pre-validated by DNS software:
. "a string of labels each containing up to 63 8-bit octets, separated
by dots, and with a maximum total of 255 octets." This makes it
impossible to satisfy the "1-KB" requirement.
. Actually, glibc's DNS resolver can produce hostnames of up to
(almost) 1025 characters (in case of bit-string labels, and special
or non-printable characters). But this introduces backslashes ('\\')
and makes it impossible to satisfy the "digits-and-dots"
requirement.
You would effectively have to control the DNS server, or spoof its responses, to get the software to accept a suitable exploit.
>You would effectively have to control the DNS server, or spoof its responses, to get the software to accept a suitable exploit
would you? If you want to exploit something that does unauthenticated gethostbyaddr(), then yes, for that you need to control a DNS server (which, btw, isn't harder than controlling a web server to serve malware with).
On the other hand, if you can make your target call gethostbyname() on an arbitrary string, you don't need to control a DNS server.
There are many sites out there that go and fetch user supplied URLs - for example to fetch picture previews.
First you exploit one of these, install a DNS server on them and then you can also exploit the ones which only do gethostbyaddr() :-)
Web servers serving malware are exploited in drive-by scanning; find a vuln in a webapp, drop your malware. It doesn't even take exploiting the system itself, and generally does not affect the web server at all. Taking over a DNS server would take much more work to pwn first, and then require reconfiguring the DNS server. Much more difficult.
Fetching a user-supplied URL is not enough to exploit remotely. You have to exploit the target's DNS resolver, because you have to feed it invalid or impossible records. All existing DNS resolvers will reject these because they break RFC.
It would be much easier to exploit a web app and drop your payload and exploit it locally, which is what everyone currently does to pwn servers with rootkits.
Adding a tagline, media friendly name or keywords is unprofessional. Simply, severity is then ranked by how popular the press or security bloggers can market the word, not by the respective severity of the CVE. Its a popularity contest, nothing more.
As someone who deals with every damn sensationalist story at a financial company, having every fucking client phone up about every damn marketoid creation even if it doesn't affect our platform detracts from doing real work.
"Professionalism" is overrated. And this appears to be a "drop everything and fix it" bug, so the "damn sensationalism" is warranted. If clients calling you about a vulnerability bothers you, get out of this line of work, please.
People actually giving a shit about security holes is something we've been wanting for a long time. It beats the hell out of the alternative, something we've been dealing with since the 90s or so!
That's not the point. The mass media knows nothing about security.
Here is what is happening when vulnerabilities get their own brand names, with logos and marketing:
1. Vulnerabilities are implicitly severe if they attract media attention (and only if they attract media attention). I've been featured in the press twice for vulnerabilities. Neither of them were as serious as the least serious, unpublicized vulnerability on this page: https://hackerone.com/internet.
2. It implicitly encourages rating a vulnerability's severity by how much media attention it receives, not by an objective scale.
It's causing a race to the bottom where coordinated disclosure now requires a PR firm, a presskit, a logo, and a brand name. For Heartbleed and Shellshock, sure, they're serious enough for all those hoops. For everything else, the race to the bottom will commoditize these things, making vulnerabilities without them ignored, and confusing vulnerabilities with them as severe.
The final result is that it's just extra, meaningless noise tacked on to vulnerability disclosure that makes it more difficult to achieve, involves more parties and doesn't improve anything.
Having a shorthand to refer to the bug makes it more easy (and therefore more likely) that it will get referenced and discussed.