You have to be kidding me. It took so long to decipher what I wanted to know that I went elsewhere.
Edit: "masterful communication" this is not, since the reader doesn't know who the page is aimed at. Even a line at the top saying "Technical people go _here_", and then something aimed at technical people would be better.
That's an enormous win.
Compared to what? Awareness and server-side adoption of fixes for issues at this level of criticality is not a problem our industry has.
A problem we used to have, however, is people engaging in grandstanding and irresponsible disclosure, leaving users insecure and catching the industry flat-footed.
Empty scare marketing is a solution to a problem we don't have. It's also a great tool for self-advertisement, and I can only assume that's why patio11 jumped on it.
I probably don't agree with that. I think there are plenty of systems in our industry that aren't actively maintained and don't have dedicated ops to manage them. A fix to a bug this large in magnitude needs to find their way onto those systems.
I refer you back to this recent article, which was also discussed extensively here: http://arstechnica.com/security/2014/03/ancient-linux-server...
'Our industry' is not just the parts people are proud of, it includes a multide of craptacular bit players that nevertheless participate in the information economy.
I think that cost is outweighed by the significant increase in exposure.
I'm not saying to make it difficult for people to understand the root cause. We should strive for both. But if I had to choose one over the other I think for a bug this big that marketing it as such wins.
The long tail.
Normally, to get out of the standard sysadmin patch rut and into an expedited state, your bug needs to convincingly cough up code execution. Since this bug didn't do that, but was nonetheless very severe, it makes perfect sense to me that additional marketing was required to expedite fixes.
It's among the most widespread Internet bugs, but:
* An identical bug impacted nginx a few years ago
* A far worse bug impacted Debian (when they commented out the randomness in their CSPRNG), which coughed up code execution on tens of thousands of machines; lots of companies that didn't officially deploy on Debian still had a Debian box somewhere vulnerable
* The Rails YAML bug was perniciously exposed in lots of places for months after the initial disclosure, and also coughed up code execution
Losing authenticators for "live" users and TLS private keys is bad, but it's not the kind of bad where you invariably need to nuke your servers from orbit and rebuild. Other widespread bugs were actually like that.
For example if I announce a new processor, I'll announce its clock speed, number of cores. If I feel like getting in depth cache levels, and bus speed. A technical person will still have a million questions. But my announcement isn't for them, its for the lowest common denominator of people who care. Often times who have no clue of every technical aspect. Only the most simplistic understanding of the topic, if any at all.
It's not for non-technical folks, either, because there's nothing they can possibly do other than be confused.
It's empty self-promoting marketing that sent the entire industry scrambling.
For updates to be deployed, the patches need to be integrated, tested, packages/updates build, and the update mechanisms tested. For complex systems -- like, say, embedded hardware -- this might involve targeting quite a few different devices and testing matrixes.
Even scrambling, this can take days, and leaves users blowing in the wind in the meantime.
This is why we have coordination with vendors PRIOR to public release, such that when the vulnerability is publicly disclosed, updates are available through standard update pipelines, the process is documented, and the update is known to be correct and not introduce deployment regressions.
A vulnerability of this severity needed no marketing. Grandstanding for non-technical users simply increased the likelihood that they'd be exploited while vendors rushed out fixes.
I understand that vendors find it inconvenient to field questions from users like "Are you vulnerable to Heartbleed?", most particularly when they are, in fact, vulnerable to Heartbleed. I respect that Yahoo feels embarrassed that there is a screenshot showing usernames and passwords in the clear. I think that the feelings of Yahoo users who would be discomfited that their email accounts are available to anyone with a command line deserves at least as much deference.
I also think it is a radically borked threat model which suggests that attackers only find out about vulnerabilities when the man-on-the-street does rather than when really-savvy-vendor-folk do.
> I also think it is a radically borked threat model which suggests that attackers only find out about vulnerabilities when the man-on-the-street does rather than when really-savvy-vendor-folk do.
And yet, this is true. A small number of people with a vulnerability provides a small threat exposure, because their attacks are simply more likely to be targeted.
Everyone with a vulnerability provides a large threat exposure, because suddenly every single script kiddie on the planet had a window to target a Python script at Yahoo or GitHub or Amazon and troll through web server's memory.
You think it was worth exposing GitHub's private company repositories to every script kiddie on earth, just because a small number of people had an incredibly valuable zero-day that they would wish to hold in reserve for high priority targets, lest it get burned and they lose the zero-day?
Do you have a study? I remember an article here that suggested most Windows attacks were created by reverse-engineering MS patches rather than by discovering the vulnerabilities or reading about them on mailing lists; if that's the threat model then co-ordinating so that most vendors release patches at the same time is safer even if it means waiting longer for a patch.
Once you have a whiff of where the bug is, it's dramatically easier to find it. You don't need to know exactly what the bug is; you just need to reduce the problem from "read all of OpenSSL" to "read a small subset of OpenSSL". Once that narrowing of the target space happens, independent discovery is inevitable. The people most motivated to do that discovery work don't have any of your best interests at heart.
Are you talking about Responsible Disclosure? Cause I thought that existed because if security researchers tell vendors in private only, then the vendors sit on it and do nothing, but if you tell the public first, users are vulnerable before the vendor releases a fix.
Isn't the only reason there's a public release as a threat to keep the vendors honest?
I figure there is because most of the HN community inhabits it, and I most certainly do.
I think this is a case where the message could have been more concise.