Hacker News Reader

Comment by csmeu | Hacker News Reader

I'm glad the moderator removed GHOST from the subject line. CVEs don't need a media friendly handle.

Edit: Its back again. Booooo.

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.

From http://www.openwall.com/lists/oss-security/2015/01/27/9 :

  --[ 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.

I think the parent comment was sarcastic.

I wasn't being sarcastic.

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.

Let's play their trick:

Its the X Factor of security.

"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!

Professionalism is thinking and understanding before you start firing a gun at your infrastructure, testing stuff and not shooting client SLAs.

We do that bit between the CVE being announced and patching ahit, not when the press goes ape shit.

So, that's overrated is it?

Yes. When there's an exploit available now, you really don't have that luxury.

His point is that severity is orthogonal to the coolness of vulnerability names. And that this will cause whacky priorities in future.

Plus, 99% of the time, end users are not directly responsible for patching these issues. So why the focus on mass-media friendly marketing?

If the mass media is getting real life sysadmins to get bugged about security holes, how is that anything but a net positive?

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.

I don't think so.

Between Heartbleed and Shellshock, and now this, a PR firm marketing vulnerabilities like this seems... crass.

I think it's okay to assign a media name to vulnerabilities, but only if the vulnerability is truly severe enough (easy to exploit and serious magnitude) to warrant it. Otherwise it's just an attempt at marketing and PR.

In this case, it looks the name is probably not warranted.

plus the original email was sent from a PR agency.

Reply on news.ycombinator.com