Hacker News Reader

Comment by phillmv | Hacker News Reader

Yes entirely on name, visual identity and first three paragraphs. More like this for serious vulns, please.

Also, what a great name.

The remaining of the page is a loud reminder of the gap between the sec and dev communities, at least as practiced in lolstartupland. Or at least between offence and defence. The second paragraph tells you the sky is falling, and then it takes them 13 questions to tell you which openssl versions are vulnerable.

(Also, I wish the behind the scenes action was less messy; why not coordinate with Debian and RedHat patches? Why did Cloudflare get advance notice?)

View on HN

But can we still have the CV numbers as well please.

"The security community refers to vulnerabilities by numbers, not names. This does have some advantages, like precision and the ability to Google them and get meaningful results all of the time"

I wish everyone embedded a Dewey Decimal number into their factual pages. Would be ace.

"I saw some kvetching on Twitter to the effect that the logo designer heard about Heartbleed before the distribution maintainers at e.g. Ubuntu and RedHat did."

Updates for Debian and CentOS landed within hours. Would have been nice to have them as we read the page.

Interestingly nothing (apparent) for Manjaro yet. Manjaro is a staged version of Arch which I have installed on a test machine to sample Gnome 3.12 when it lands in the repository a week or so.

    [keith@mocha ~]$ openssl version
    OpenSSL 1.0.1f 6 Jan 2014

Sort of ties in with

http://allanmcrae.com/2013/01/manjaro-linux-ignoring-securit...

perhaps. I get the impression that Manjaro (and other similar client OSes) are mainly for end users and not on servers.

The CV number is on http://heartbleed.com/

CVE-2014-0160 is the official reference to this bug. CVE (Common Vulnerabilities and Exposures) is the Standard for Information Security Vulnerability Names maintained by MITRE. Due to co-incident discovery a duplicate CVE, CVE-2014-0346, which was assigned to us, should not be used, since others independently went public with the CVE-2014-0160 identifier.

Replying to my own comment as edit time has passed.

Manjaro: update arrived this morning, may have been available for past 12 hours, so promoted through the 'staging' cycle. Half a day to a day later than Ubuntu/Debian/Redhat if I have my times correct.

    [keith@mocha ~]$ openssl version
    OpenSSL 1.0.1g 7 Apr 2014

There is no doubt that masterful branding of the bug helped with patching of vulnerable systems in this case. It is not at all clear that the trend it will surely start will be a good thing. Marketing does improve visibility. But it also, inherently obscures the truth. Even in this case: some people on HN don't know that it was a Google researcher who first discovered/reported the bug; the actionable/technical information on the bug was hidden below the fold because the primary goal of the page was to be a long term marketing tool for the security firms, not the shortest path to patch vulnerable systems. We will see how this trend develops but I would not be surprised if we get more and more marketing with less upside (necessary visibility) and more downsides.

I seriously wished they had something like:

Step 1: Run this command. If it returns "Your vulnerable!" go to step 2.

And so on, with actionable steps that people could quickly understand and circulate.

Because Cloudflare is possibly the biggest and most vulnerable target due to the enormous number of websites and businesses relying on it. I would not be surprised if at least FB and Twitter also had early access.

It was clear from the beginning that as soon as the details became public, a race would begin for the script-kiddy-friendliest tool to own sites/users. And the most likely targets of script kiddies should be warned in advance.

And what about Google? and Amazon? And banks? And .gov sites?

I'm not sure how you can handle this in any different way as they did, really.

Google discovered the bug.

Google was one of the discoverers. From the page:

...independently discovered by a team of security engineers (Riku, Antti and Matti) at Codenomicon and Neel Mehta of Google Security

Would be interesting to know if the production people at Google rolled out a fix before general announcement. E.G. is internal communication in such a large organisation still faster than intertube?

> Because Cloudflare is possibly the biggest and most vulnerable target due to the enormous number of websites and businesses relying on it.

AWS is at least as important, as is Akamai.

My point being, it's not enough to hand-wave about who's the biggest and most important. A good system would give anyone with enough at risk a clear path to earn a seat at the table.

Major providers could create an "early warning disclosure club", each contributing some money annually, and the money can be used to pay bounties to anyone who gives them advance warning of a zero day. Of course you'd want some safeguards to make sure nobody blackhat joins the club to use the vulnerabilities for offense.

Akamai was notified and completed the patch in advance of public disclosure according to their Heartbleed FAQ: https://blogs.akamai.com/2014/04/heartbleed-faq-akamai-syste...

This raises the question about whether Amazon/AWS was notified prior to public disclosure.

How do you notify a large-ish group of a secret vuln without notifying any of the bad guys?

Because if you notify the bad guys at the same time, then you've made it worse, since people you didn't notify don't know anything is up yet.

Software security used to work this way, in the early 90s. Disclosures went to vendor cabals. They leaked like sieves and were a running joke on #hack.

It's hard to argue: yes, the world would be better if only the people who were going to mitigate the bug had the information until everyone had mitigated. But a repeal of the CAP theorem would be nice too. Meanwhile, we have to work with the world we have, not the one we want.

Early disclosure club isn't a terrible idea, but good luck getting it funded in a serious way. The correlation between "most impacted" and "most clueful" isn't particularly strong.

Indeed, if one posits a channel for transmitting secrets among a vendor cabal which never leaks to people not authorized to receive the secrets, we should abandon SSL and use that for our secure communication needs instead.

Information isn't supposed to stay in the Cabal for long. If you want 6 months (or, more typically 5 years) to fix a serious vulnerability, you shouldn't get any kind of useful protection.

It still obviously does work this way, just very informally. That is, such cabals clearly exist and clearly get early access. If things seem different now, perhaps it's because the timelines are shorter or the cabals more consolidated.

As for "most clueful": I have often lamented the current pendulum swing toward a centralized internet. But this is one area where all the centralization of infrastructure has a benefit. An awfully large fraction of the internet's data is in the hands of a small number of relatively tech-clueful organizations.

How many of Heroku's or AWS's or Akamai's customers would still be unpatched right now if those customers were managing things themselves? I'd put any of those organizations safely ahead of their median customer in the "clue" department.

I'm not going to disagree with your main point though: funding for security is always an uphill battle. When it's working great, nothing happens.

there are plenty of more important sites than FB and twitter, sites that store credit card info, bitcoins or generally any sensitive info. FB and Twitter are essentially public sites, if you post something there it is likely for public consumption (limited public but still there for people to see). If someone gets a password for your FB account it is far less serious than if they get your amazon password or your banking password.

Heartbleed is not super descriptive to layfolk but it's certainly catchy, I'll give you that. Having a dot-com domain with said simple name was great, too.

But the content? A loud reminder indeed. As a member of the dev community, I would have wanted to see the following:

1. How bad is it? If you're using SSL, then an attacker may be able to read your machine's memory without leaving a trace.

2. Who is affected? Users of OpenSSL versions X-Y. Check your site here [http://filippo.io/Heartbleed/], but your client code may be affected too!

3. How do I secure myself? Update to OpenSSL version Z, reboot, and consider resetting all sensitive data on your server (reissue your SSL certificate, reset your user passwords and sessions, etc).

These facts are littered throughout a 2,000+ word document. In the future, I would like to see these things answered plainly at the very top.

offtopic: do you have a trademark for the lolstartupland word? ;-)

Reply on news.ycombinator.com