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?)
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
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.
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.
> 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.
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.
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.
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.
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?
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.
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?)