Slashdot Mirror


Heartbleed Sparks 'Responsible' Disclosure Debate

bennyboy64 writes: "IT security industry experts are beginning to turn on Google and OpenSSL, questioning whether the Heartbleed bug was disclosed 'responsibly.' A number of selective leaks to Facebook, Akamai, and CloudFlare occurred prior to disclosure on April 7. A separate, informal pre-notification program run by Red Hat on behalf OpenSSL to Linux and Unix operating system distributions also occurred. But router manufacturers and VPN appliance makers Cisco and Juniper had no heads up. Nor did large web entities such as Amazon Web Services, Twitter, Yahoo, Tumblr and GoDaddy, just to name a few. The Sydney Morning Herald has spoken to many people who think Google should've told OpenSSL as soon as it uncovered the critical OpenSSL bug in March, and not as late as it did on April 1. The National Cyber Security Centre Finland (NCSC-FI), which reported the bug to OpenSSL after Google, on April 7, which spurred the rushed public disclosure by OpenSSL, also thinks it was handled incorrectly. Jussi Eronen, of NCSC-FI, said Heartbleed should have continued to remain a secret and be shared only in security circles when OpenSSL received a second bug report from the Finnish cyber security center that it was passing on from security testing firm Codenomicon. 'This would have minimized the exposure to the vulnerability for end users,' Mr. Eronen said, adding that 'many websites would already have patched' by the time it was made public if this procedure was followed."

188 comments

  1. No Good Solution. by jythie · · Score: 5, Insightful

    This really strikes me as the type of problem that will never have a good solution. There will always be competing interests and some of them will be mutually exclusive while still being valid concerns.

    1. Re:No Good Solution. by gweihir · · Score: 3, Insightful

      Indeed. But there is a _standard_ solution. Doing it in various ways is far worse than picking the one accepted bad solution.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    2. Re:No Good Solution. by Opportunist · · Score: 3, Interesting

      Standard means jack. As long as there is no good reason (like, say, avoiding a fine that breaks your back or jail time) bugs like that are not being told, they're being sold.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    3. Re:No Good Solution. by gweihir · · Score: 1, Troll

      That is BS. You are mixing two things to make your non-existing point: People that want to disclose and people that want to sell. The second ones are always black-hats, even if some of them pretend otherwise.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    4. Re:No Good Solution. by Anonymous Coward · · Score: 3, Interesting

      There is no right, it's already gone bad so you've just got a lot of wrongs to choose from. So my opinions on disclosure are informed by risk minimization. Or to borrow a term, "harm reduction."

      The order people were informed about heartbleed smells more like matter of "It's about who you know." than getting the problem fixed. If OpenSSL isn't at or or real close to the top of the list of people you contact the first day, you're either activity working against an orderly fix or don't trust the OpenSSL folks with the knowledge to fix their own software and are beyond a healthy level of paranoia.

    5. Re:No Good Solution. by Anonymous Coward · · Score: 1

      You are missing the third choice- people who disclose publicly and irresponsibly to the public before the developers as a means of scoring some shallow PR points. This one also involves Google researches usually as it pertains to Microsoft.

    6. Re:No Good Solution. by Anonymous Coward · · Score: 1

      Doing it in various ways is far worse than picking the one accepted bad solution.

      Worse for who?

      Once you recognize that there are competing interests, then what's best for you might not be best for me, and you and I are going to do different things.

    7. Re:No Good Solution. by Fnord666 · · Score: 1

      Indeed. But there is a _standard_ solution.

      Citation needed.

      --
      'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
    8. Re:No Good Solution. by mwvdlee · · Score: 1

      So the solution to competing interrests and mutually exclussive valid concerns is to always pick only one concern/interrest and always ingore the others?
      Good luck with that.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    9. Re:No Good Solution. by lgw · · Score: 1

      Therefore the best solution is to public release so everyone has the information at the same time. Let them compete for the patch; Awful software publisher will be the one caught with bugs. Good one will be patch and secure while everyone else suffer their bad choice.

      Over time the best software will prevail and only idiots will still be using Microsoft products... that the theory. In practice there is corruption and bad software will linger for decades.

      It's not about how fast you patch, it's about how fast you can get patches to your customers. And for the OpenSSL flaw, there were devices where the patch process is "throw it away and buy a new one".

      Anyhow, Microsoft is far and away the worlds leading expert at distributing security patches - no one really has more experience or such a well-tuned corporate ecosystem. MS pushed a critical security patch out to WU, and every major corporation knows just what to do, and understand the urgency, and has a well-travelled path for it. The more modern players are good at patching consumer endpoints, but haven't really addressed corporate customers.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    10. Re:No Good Solution. by gweihir · · Score: 1

      I don't.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    11. Re:No Good Solution. by manquer · · Score: 1

      Different people are motivated by different things: security,money, or street cred,or just for fun, the reporter is under no ethical,legal or moral obligation to disclose to anyone in any manner; he is not the manufacturer it is not his fault the bug is there or his responsibility he did not built software/service using the buggy software that people paid for.

      Preferential disclosure done which ever way is bad. Chances of black-hats getting hold of it becomes higher, if *some* special people know of it before others; what guarantee is there some dissatisfied employee won't leak it. what makes google, or Red Hat more special than Average Joe running his applications on top of OpenSSL with potentially compromised keys ?

      Responsible disclosure has to be fully public; it ensures the manufactures fix it faster; there are vendors who fix zero-days only if they get exposed public exposure. just look at the way oracle fixes java zero days.

    12. Re:No Good Solution. by sl149q · · Score: 1

      The answer is actually simple. Once you have determined that there is an (to quote Bruce Schneier) 11 out of 10 security problem you need to get the servers turned off. Everywhere.

      If the FBI or Interpol or Bruce Schneier basically said "There is a serious exploit in OpenSSL, you (as in every organization running it) need to shut down every server now, we will provide the details and fix in 48 hours."

      Yes, the bad guys will now know that OpenSSL has an exploit. But they won't exactly know where to start looking. And you now have a tilted the foot race for exploitation back towards the good guys. They do need to move fast and get the servers disabled. And perhaps redeploy using alternate non-involved servers (in this case non openSSL.) But that will be better than letting the black hats jump in and know immediately what the exploit is and start using it.

      In any case sounds like we need an RFC and strict protocol for this.

  2. WTF? by gweihir · · Score: 5, Insightful

    The only possible way is to disclose to the responsible manufacturer (OpenSSL) and nobody else first, then, after a delay given to the manufacturer to fix the issue, disclose to everybody. Nothing else works. All disclosures to others have a high risk of leaking. (The one to the manufacturer also has a risk of leaking, but that cannot be avoided.)

    The other thing is that as soon as a patch is out, the problem needs to be disclosed immediately by the manufacturer to everybody (just saying "fixed critical security bug" is fine), as the black-hats watch patches and will start exploiting very soon after.

    All this is well known. Why is this even being discussed? Are people so terminally stupid that they need to tell some "buddies"? Nobody giving out advance warnings to anybody besides the manufacturer deserves to be in the security industry in the first place as they do not get it at all or do not care about security in the first place.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:WTF? by Tom · · Score: 4, Interesting

      The only possible way is to disclose to the responsible manufacturer (OpenSSL) and nobody else first, then, after a delay given to the manufacturer to fix the issue, disclose to everybody. Nothing else works. All disclosures to others have a high risk of leaking. (The one to the manufacturer also has a risk of leaking, but that cannot be avoided.)

      It's not about leaking. The reason I'm not alone in the security community to rage against this "responsible disclosure" bullshit is not that we fear leaks, but that we know most of the exploits are already in the wild by the time someone on the whitehat side discovers it.

      Every day you delay the public announcements is another day that servers are being broken into.

      --
      Assorted stuff I do sometimes: Lemuria.org
    2. Re:WTF? by paskie · · Score: 2

      "Very well known?" This is very much *not* the way how for example many security bugs in linux distributions are handled (http://oss-security.openwall.org/wiki/mailing-lists/distros). Gradual disclosure along a well-defined timeline limits damage of exposure to blackhats and at the same time allows enough reaction time to prepare and push updates to the user. So typically, once the software vendor has fixed the issue, they would notify distributions, which would be given some time to prepare and test an updated package, then the update is pushed to users at a final disclosure date.

      For a bug of such severity, I'd agree that the embargo time of 7-14 days used by distros@ is way too long. But a 12-24 hour advance announcement would be quite reasonable. Large website operations typically may have suitable staffing to be able to bring a specific update for a critical bug (similar in potential damages to a service outage) online within 6-12 hours, so a next step would be passing the information from distributions to these users (e.g. via a support contract with distros@-subscribed vendor).

      In this timeframe, you have a good chance to prepare updated packages for major archs and do an emergency rollout. At the same time, even if there is a leak, the leak needs to propagate to skilled blackhat developers, they need to develop an exploit and this exploit needs to get propagated to people who would deploy it in the remaining time frame.

      --
      It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams
    3. Re:WTF? by Anonymous Coward · · Score: 4, Insightful

      If no fix is available yet, they're still being broken into - but you've just added the thousands of hackers who *didn't* know about it to the list of those exploiting it.

    4. Re:WTF? by WD · · Score: 1

      "High risk of leaking?" And what would the consequences of such a leak be? The affected vendors are only slightly better off than they were with how it actually turned out with Heartbleed?

      When Heartbleed was disclosed, virtually no affected vendor (e.g., Ubuntu, Cisco, Juniper, etc.) had an update available. So there was a window where the vulnerability was public, but nobody had official updates from their vendor that would protect them. You are claiming that this is better than a coordinated release, where there would have been actual updates available to install?

      It's not "buddies" that is being discussed here. It's the people producing the software that is affected!

    5. Re:WTF? by bill_mcgonigle · · Score: 1

      There's no one-size fits all solution. I've made the argument for informed disclosure here in the past, but in this case it probably wouldn't work. The DTLS code is so small and self-contained and the code so obvious to an auditor that just saying that there's an exploit in DTLS or to compile without heartbeat is probably enough to give the blackhats a running start. But there are other situations where informed disclosure is better than responsible disclosure.

      Did Google do the right thing here? I'm not sure, but it's not completely clear that they didn't. There are several factors that bridge the gap between theoretical ideal and what can work in every situation in the real world.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    6. Re:WTF? by Wycliffe · · Score: 1

      It's not about leaking. The reason I'm not alone in the security community to rage against this "responsible disclosure" bullshit is not that we fear leaks, but that we know most of the exploits are already in the wild by the time someone on the whitehat side discovers it.

      Every day you delay the public announcements is another day that servers are being broken into.

      So are you going to take your server offline until there is a patch? Or are you going to write a patch yourself?
      I think giving the software vendor 2 weeks to fix the bug (1 week if it's trivial or you provide the patch)
      is reasonable as 99% of people are not going to be able to do anything about it until there is a patch anyways.
      As soon as the patch is available then it should be publicly announced.

    7. Re:WTF? by jones_supa · · Score: 1

      Exactly this.

    8. Re:WTF? by Anonymous Coward · · Score: 0

      This bug does represent an exposure, but on some linux systems there is a bug trapping app-suite (rpm -qa "abrt*") which will dump a buggy app and send its dumps up to the mothership. Consider the adobe flash player, involved in many crash/cash transactions and has never been stable. I have seen android "antivirus" apps which anly need permissions for your phone list and network access. Wonder what they do? The credit card industry is boinked almost daily now and no changes. NSA pirating data feeds... Backdoors in principle encryptions... The heartblead bug needs to be fixed, but the real work is still very much out there.

    9. Re:WTF? by drinkypoo · · Score: 1

      Every day you delay the public announcements is another day that servers are being broken into.

      Yes, but it's also easier to make use of the exploit information to produce an exploit than a patch. That's why it's responsible to report the bug to the maintainers before announcing it publicly. But your argument is the reason why you don't wait indefinitely for the maintainers to kick out a patch, either.

      As usual, the answer lies somewhere between extremes.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    10. Re:WTF? by fustakrakich · · Score: 1

      That's just too bad. Public announcement is the way to fix the problem as fast as possible.

      --
      “He’s not deformed, he’s just drunk!”
    11. Re:WTF? by medv4380 · · Score: 4, Interesting

      Not to sound like too much of a conspiracy nut, but Heartbleed did look like a deliberate exploit to some people, and still does to others. If it had been, and had been put there by someone at OpenSSL they are the last ones you actually want to inform until you have already patched it yourself. From the timeline that's what Google did, and then tapped the shoulders of their closes friends so they could ether patch it or disable the heartbeat feature as CloudFlare did. I agree that OpenSSL should have been informed first, but what do you do when you suspect the proper channels are the ones who put it there in the first place.

    12. Re:WTF? by Anonymous Coward · · Score: 1

      If no fix is available yet

      There's always a fix.

      It might involve yanking a power cord, but it will absolutely guarantee nobody is breaking in.

    13. Re:WTF? by Anonymous Coward · · Score: 0

      So are you going to take your server offline until there is a patch? Or are you going to write a patch yourself?

      Or, option (3): disable Hearbeat. Then again, if you're a bank and option (3) isn't available, then it makes a lot of sense to choose option (1) instead of crossing one's fingers on an active exploit not being used on your server(s).

      I think giving the software vendor 2 weeks to fix the bug (1 week if it's trivial or you provide the patch)
      is reasonable as 99% of people are not going to be able to do anything about it until there is a patch anyways.
      As soon as the patch is available then it should be publicly announced.

      What's reasonable for you may not be reasonable for me. If there's an older version to switch to or a 100% mitigation technique, why should I or lots of others wait two weeks? Because some people may not be aware of the announcement and/or they'll continue to run a vulnerable system? Well, that happens even after the patch is released because lots of people aren't anal retentive about patching updating, it takes time to verify any patch that's released regardless*, some software simply can't be updated, and plenty just don't care enough to do anything about it.

      Really, the logic behind your argument says more about (1) responsible disclosure should be prompt and well published to minimize the delay before people can act and (2) responsible disclosure should include sufficient mitigation techniques, if possible, to address the issue. After all, a patch may be nothing more than a mitigation technique. So, why place such emphasis on one sort of patch over another?

      *And this is yet another major argument for early announcement since if it takes up to two weeks to verify and deploy a mitigation technique, then by the time an "official" patch would be released would be the time a lot of companies would already have made the problem a non-issue. I mean, the whole point of giving the vendor so many weeks is precisely because there is the risk of unintended consequences and companies who want to deploy a patch have to verify against their own things of which the vendor simply can't. It's not that the patch writing takes anywhere near two weeks. So, instead of having to rush through verification by the vendor and then by the company, a possibly much simpler mitigation technique can be used and the patch can be thoroughly tested as part of the standard update cycle. After all, the end objective on the end user side is to not have the bug being actually exploited; the how and why are much more moot--just like the ideology of full disclosure for the sake of full disclosure doesn't seem to trump your pragmatic concerns of actual exploits.

    14. Re:WTF? by Ardyvee · · Score: 1

      Couldn't sys admins disable the heartbeat feature as a preventive measure while the patch was prepared? Please note that I'm rather ignorant on all the things involved, but AFAIK the feature in question in the very recent case was not crititcal and could be disabled with minimal damages to the functioning of the service.

      I agree with you, though, that the developers should be informed of it first. But I also think that it depends on the issue. If you tell me that feature x in software a has a security issue and I can live without feature x while devs fix it, I think I would rather know so I can disable it instead of waiting for a patch. Just saying.

      --
      I don't care if I'm wrong. I only care about everyone obtaining something from the discussion.
    15. Re:WTF? by Ardyvee · · Score: 1

      But isn't the Heartbeat feature a part of the software that is optional and can be disabled?

      --
      I don't care if I'm wrong. I only care about everyone obtaining something from the discussion.
    16. Re:WTF? by Tom · · Score: 1

      As usual, the answer lies somewhere between extremes.

      My preferred choice of being left alone or being beaten to a pulp is being left alone, not some compromise in the middle, thank you. Just because there are two opposing positions doesn't mean that the answer lies in the middle.

      I've given more extensive reasoning elsewhere, but it boils down to proponents of "responsible disclosure" conveniently forgetting to consider that every delay also helps those bad guys who are in posession of the exploit. Not only can they use it for longer, they can also use it for longer against targets who don't know they are vulnerable.

      Many, many companies run non-essential services that they would not hesitate to shut down for a few days if they knew that there's an exploit that endangers their internal systems. Other companies could deploy mitigating measures while waiting for the patch.

      Don't pretend sysadmins are powerlessly waiting with big eyes for the almighty vendor to issue a patch.

      --
      Assorted stuff I do sometimes: Lemuria.org
    17. Re:WTF? by Tom · · Score: 1

      So are you going to take your server offline until there is a patch?

      Depends, but yes for many non-essential services, that is indeed an option. Imagine your actual web service doesn't use SSL, but your admin backend does. It's used only by employees on the road, because internal employees access it through the internal network.

      Sure you can turn that off for a week. It's a bit of trouble, but much better than leacking all your data.

      Or if it's not about your web service, but about that SSL-secured VPN access to your external network? If you can live without home office for a week, you can turn that off and wait for the patch, yes.

      Most importantly, who are you to decide that everyone should wait for a patch instead of giving people the opportunity to deploy such mitigating measures?

      I think giving the software vendor 2 weeks to fix the bug (...) is reasonable

      People don't learn.

      We used to do that.

      Full disclosure evolved primarily as a countermeasure because vendors took those grace periods not as a "we need to get this fixed in that time", but as a "cool, we can sit on our arses doing nothing for another two weeks".

      --
      Assorted stuff I do sometimes: Lemuria.org
    18. Re:WTF? by drinkypoo · · Score: 1

      Don't pretend sysadmins are powerlessly waiting with big eyes for the almighty vendor to issue a patch.

      But most of them in fact are in that situation. If you want to make no real sysadmin comments, I may well agree, but it doesn't change much.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    19. Re:WTF? by Tom · · Score: 1

      Yes, this argument is being made a million times and it doesn't prove anything because it rests on so many assumptions that may or may not be true that it's total truth value is about as good as tossing a coin.

      The two most important:

      First, you assume that the official patch is the only thing that can be done. In many, many cases there are other (temporary) measures that can be taken to mitigate a problem or limit its impact. Who are you to decide for everyone on the planet with their different needs and scenarios which is better?

      Second, you assume that there are thousands of hackers who didn't know about it. Yes, it is likely that the number of bad guys knowing about the problem was less than 100% before the announcement. But any real professional doesn't care about number of hackers, he cares about risk, which is number multiplied by impact. If the people who are the worst danger to my business and are most likely to target me already have the exploit, I don't give a fuck about a thousand random script kiddies also getting it.

      --
      Assorted stuff I do sometimes: Lemuria.org
    20. Re:WTF? by gweihir · · Score: 1

      Sorry, but that really is nonsense. All that immediate disclosure can cause is panic. It does not help at all. It increases attacks in the short-term, because most people are not able to do anything without patch.

      Sure, you can argue for very short time given to the manufacturer, like a few days (they will not make that large a difference for the ones already using the weakness, most weaknesses exist for quite a while before they are discovered by the white-hats and analysis also takes some time), and some companies have been abusing responsible disclosure by delaying fixes for months and months, so I am all for that. The thing is that the manufacturer must not be the one to set the time they get to fix this. But giving them zero time is just intentionally destructive.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    21. Re:WTF? by gweihir · · Score: 1

      Not really. Disabling the patch took changing the sources manually and rebuilding OpenSSL, something most sysadmins cannot do or cannot do fast.

      I think the main problem with the flavor of responsible disclosure some part of the security community is raging against is that this flavor allows the developers to say how long they need, and that has been abused. But giving them zero time is just malicious.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    22. Re:WTF? by gweihir · · Score: 1

      And to amplify it in the meantime. Well done.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    23. Re:WTF? by gweihir · · Score: 1

      Apparently you have not heard about companies that collapse if they are offline for a day or so. But then, with the level of stupidity your answer displays, you would not have...

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    24. Re:WTF? by gweihir · · Score: 1

      I am not talking about giving the manufacturer a lot of time. But if the bug is already exploited in the wild, chances are it has been for a while, so a few more days matter little. However, quite often nothing can be done before a patch is available and then too early public disclosure does a lot more harm than good.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    25. Re:WTF? by gweihir · · Score: 1

      Indeed. There is however a certain type of wannabe "hacker" that needs to turn things into power-plays. These will disclose immediately and inflate their ego that way, no matter what damage this does.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    26. Re:WTF? by gweihir · · Score: 1

      In many large organizations, you have segregation of duties. This boils down to the sysadmins not being allowed to patch and recompile code. They are allowed to install a vendor patch though. And yes, segregation of duties is a good idea.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    27. Re:WTF? by Tom · · Score: 1

      The thing is that the manufacturer must not be the one to set the time they get to fix this

      I agree on that 100%

      most people are not able to do anything without patch.

      That depends a lot on the particular problem. In many cases, there are mitigating measures that can be taken until a patch is available, and I'd argue strongly that the people affected should make the call on that, not you or I or anyone else.

      By withholding information, you are making decisions for other people. But you are not in a position to make that call, because you are not the one who suffers the consequences.

      I advocate for giving everyone all the information so they all can act according to their needs and abilities. I argue for letting people make their own decisions.

      --
      Assorted stuff I do sometimes: Lemuria.org
    28. Re:WTF? by Tom · · Score: 1

      Absolutely.

      But we were talking about mitigating measures. That is almost never patch and recompile, it's things like turning off a service, changing the firewall rules, moving servers into a different network - things that are very much within the duties of the sysadmin (with proper clearance and risk acceptance by management, etc. etc.)

      Basically, if you have a bug that makes your internal network open to the world, but you can avoid it by disabling feature X in the config file, and your company doesn't require feature X, then that's something the sysadmin can do, and he can do it right now, while the vendor is working on a patch.

      --
      Assorted stuff I do sometimes: Lemuria.org
    29. Re:WTF? by fustakrakich · · Score: 1

      Don't care. If amplifying it speeds up the process, then it's all good. Fast response is the priority.

      --
      “He’s not deformed, he’s just drunk!”
    30. Re:WTF? by gweihir · · Score: 1

      Sorry, in many large organizations, the sysadmins are not allowed (or able) to change firewall configurations either. And sign-offs, even in emergencies like these, may take a few days.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    31. Re:WTF? by Anonymous Coward · · Score: 0

      What? you can't handle adding

      -DOPENSSL_NO_HEARTBEATS

      to the spec file and rebuild the rpm? Waiting for the compile was the longest part of fixing Fedora 18 for me.

    32. Re:WTF? by drinkypoo · · Score: 1

      But we were talking about mitigating measures. That is almost never patch and recompile, it's things like turning off a service, changing the firewall rules

      But we're talking about this in the context of Heartbleed, where pre-patch mitigation involved disabling critical services... A patch is what was needed here, and nothing else would suit.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    33. Re:WTF? by Tom · · Score: 1

      You are right on those.

      Except for the "nothing can be done" part. That's not your judgement call to make. There is always at least one option - pulling the power plug - and it might well be a feasable temporary solution for some people affected.

      --
      Assorted stuff I do sometimes: Lemuria.org
    34. Re:WTF? by Tom · · Score: 1

      Yeah, there was absolutely nothing anyone could do. Oh wait, except for this brutally complex and technically challenging thing right from the official vulnerability announcement:

      This issue can be addressed by recompiling OpenSSL with the -DOPENSSL_NO_HEARTBEATS flag. Software that uses OpenSSL, such as Apache or Nginx would need to be restarted for the changes to take effect.

      That was definitely not a feasabole option for anyone on the planet...

      --
      Assorted stuff I do sometimes: Lemuria.org
    35. Re:WTF? by Tom · · Score: 1

      sysadmin, firewall admin - let's not pick nits here. The point is that there are mitigating measures, and if signing off on something that prevents your company secrets leaking out to the Internet without you even noticing takes more than 24 hours then your incident response procedures are retarded and you can hire me for a workshop to improve them dramatically.

      --
      Assorted stuff I do sometimes: Lemuria.org
    36. Re:WTF? by gweihir · · Score: 1

      Sorry, but you have your head on the clouds. This is not how reality works. And no, I do no need to hire you. I can improve things myself, with the added difference that I know what is possible in practice and what is not.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    37. Re:WTF? by Tom · · Score: 1

      You're cute. I've done this shit for a living for a while. Yes, many companies' incidence response procedures are crap, but they shouldn't, and it is perfectly possible to get an emergency countermeasure deployed within 24 hours with all the t's crossed and i's dotted and perfect SOX compliance and whatever else you need. It's just something you need to think about before the emergency hits you.

      --
      Assorted stuff I do sometimes: Lemuria.org
    38. Re:WTF? by gweihir · · Score: 0

      Seems senility has set in in your case. And I have been doing this for a while for a living too. Maybe you just have really small customers, as in less than 10k employees? They may still have the flexibility needed, both on the technological side and on the management side. You claim that this is generally possible is just plain wrong.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    39. Re:WTF? by Tom · · Score: 1

      True, most of my experience is with companies 10k, but you're just being arrogant calling that "really small". Almost all of those companies are part of a larger corporation, and you don't manage IT operating activities in multinational corporations on the corporate level. The corporate level decides if you go with SAP or Oracle, but not which patch level of Apache is used on the website of one of 20 subsidiaries.

      At least that's the way it was in my last two companies (one a subsidiary of a 65k employee corporation, one part of a 30k employee corporation). If you know of any multinational corporations where the CTO of the top-level holding has to sign off on patch deployment, let me know.

      We're talking operative emergency response here, not rollout of new corporate IT infrastructures. I hope you see the difference.

      --
      Assorted stuff I do sometimes: Lemuria.org
  3. Re:Not that good by gweihir · · Score: 1

    Mindless propaganda and, as it happens, untrue. See for example http://developers.slashdot.org...

    But I guess proponents of closed source will always use any lie that is handy, just to propagate their ideology.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  4. Disclosure!? Fix it, damn it! by Anonymous Coward · · Score: 1

    These guys are apparently competent enough to find a bug like this. The fix is damned near trivial. So "disclose" it to OpenSSL, accompanied by a patch and let OpenSSL do the rest.

  5. The disclosure was fine. by lasermike026 · · Score: 0

    Lite a fire under everyone butts and it got fixed and deployed in hours. I see nothing wrong with this. Maybe it's time to crank up the heat.

  6. As bad ideas go... by ClayDowling · · Score: 3, Insightful

    This notion ranks right up there. Manufacturer was told. Everybody else was then told. That's how it's supposed to work. This notion of "let's just tell our close friends and leave everybody else in the dark" is silly. You'd only wind up leaving most people open to exploit, because if you think your secret squirrel society of researchers doesn't have leaks, you're deluding yourself.

  7. Yes, that was handled badly by Anonymous Coward · · Score: 0, Insightful

    There should have been a public advisory telling everybody with an OpenSSL based server to shut down the server, wait for an update, install the update and only then put the server online again. The biggest mistake was to keep vulnerable servers running for even a short while after the vulnerability was published.

    1. Re:Yes, that was handled badly by Anonymous Coward · · Score: 0

      Or just disable Heartbeat, I mean that's where the vulnerability was.

    2. Re:Yes, that was handled badly by Unordained · · Score: 1

      Yes. You don't have to notify people of the exact flaw and how it can be exploited, to help them protect themselves while waiting for a patch. The immediate response should have been to tell people to disable heartbeat, or barring that, shutdown their affected systems. Yes, it would suck, but since you don't know for sure that the exploit is known only to the researchers, you should assume it's in the wild, and this is the only safe thing to do in the interim. (Could this be used as a form of DoS? Sure, if sysadmins get used to wholly shutting down services anytime there's a warning from anyone, or if the partial shutdown of one service in fact makes another service less secure. TBD.)

      All this discussion of disclosing to OpenSSL first, letting them patch, giving distros time to get updates ready ... ignores that the moment OpenSSL goes to fix the bug, the patches are public. Attackers waiting to see a flaw in OpenSSL would be monitoring version-control regularly, to see if any given patch looked interesting. While your distros are being quietly told to get updates ready, the attackers are analyzing the patch to see what kind of bug you fixed, knowing that, because there's radio silence, sites are vulnerable.

      Making a big stink about it is the only way to make sure sites actually get updated, anyway. Distros and whatnot having updates available does not get those updates installed. We don't have auto-update on any servers. As was discussed recently, many sysadmins have to submit patches to change-control boards for approval, and if there's not a furor over the issue, there's no emergency approval.

      So:
          (a) a blitz identifying only the versions affected and what to do about it,
          (b) a patch release sufficiently delayed to give end-users a chance to shutdown affected services,
          (c) a blitz about the availability of the update, which people will care about more because they've already had to take action to protect themselves, and are possibly sitting in a shutdown state.

    3. Re:Yes, that was handled badly by Anonymous Coward · · Score: 0

      No, you can not start by telling them to disable heartbeat. The heartbeat function is the vulnerable part. By revealing the exact location of the vulnerability without making sure that everybody had a chance to shutdown servers beforehand, you give attackers a window of opportunity. That's why you wouldn't tell them which versions are vulnerable either. A lot of secrets have been revealed just because vulnerable servers were kept online while the admins were waiting for patches or an opportune moment to patch. Some of those secrets may have given an attacker the ability to decrypt years of highly sensitive recorded traffic. Making sure that servers with OpenSSL are offline when the news of the exact vulnerability becomes public should have been the highest priority. It wasn't, and that made things a lot worse.

    4. Re:Yes, that was handled badly by Unordained · · Score: 1

      So does that mean you're suggesting the safest course would be to:
          (a) tell everyone to shutdown ALL OpenSSL-backed services, urgently.
          (b) after 1 day, tell everyone they can bring their 0.9.8 services back online.
          (c) after 1 day, tell the remainder that it's okay to come back online, with heartbeat disabled.
          (d) have the patch ready for distribution around this time.
      ?

      I agree with the caution. TBD:
          (1) there's the risk that telling admins to shut everything down, all versions, without telling them why, will cause them to ignore the notice
          (2) while these services are shutdown, what will admins do instead? will they use insecure services because "the show must go on"?

    5. Re:Yes, that was handled badly by Anonymous Coward · · Score: 1

      No need to stagger the disclosures. The important bit is to tell everyone that there is a trivially exploitable critical vulnerability in OpenSSL that leaves no trace in logs, so shut down the server and await further information. 24 hours later you tell everybody that the heartbeat handling is the vulnerable part, and this means that 0.9.8 servers can be brought back up as is, everybody else must either patch or disable heartbeat before bringing the servers back online. Have the patches ready as soon as possible. Have anybody who suggests that the show must go on and SSL servers can't be shut down even if there is a critical vulnerability fired.

    6. Re:Yes, that was handled badly by david_thornley · · Score: 1

      Shutting down the servers for a day will have some really major impacts on certain companies and customers. You have to provide a very good reason to urge it, and you're going to have to convince people that you do indeed know what you're doing, apparently without telling them what the vulnerability is. At that point, people can judge the possibility that you're correct against the cost (and possibly legal liability) of shutting down the servers. Different people will come to different decisions, and you don't get to fire everybody you disagree with.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  8. Web sites? End users? by Anonymous Coward · · Score: 0

    And how do you differentiate between "web sites" and "end users"? Why should Facebook be treated differently than me?

    1. Re:Web sites? End users? by Anonymous Coward · · Score: 0

      Really? Well, you I don't know. So you get the benefit of the doubt. You are probably fine. But Facebook? I'd kick them in the teeth if I could. (Since in the US our SCOTUS claims that Facebook is a person). So sure, I will treat Facebook differently than you.

    2. Re:Web sites? End users? by Squash · · Score: 1

      This is really the only point that matters in this whole discussion: Is it fair for someone to have this information before someone else. The answer isn't a simple as the question.

      If you ask me, I would want to have full immediate disclosure. The suggestion that the person reporting the bug is the first person to have found it is absurd. Black Hat interests are actively looking for these kinds of problems, and finding them is how they make a living. Forget corporations, Governments are the ones who will pay top dollar for undisclosed exploits, and something like this (enabled by default, invisible in system logs, and in software deployed so widely!) would be worth a fortune. Improperly calculating data size is the cause of nearly all of these types of bugs, so you can really save a lot of tie just examinig the lead-up to function calls that include a size parameter (memcpy() was used in heartbleed, but is just one of a group of standard C functions that you would hotlist.). But we're drifting a bit.

      Heartbleed has two classes of victims: Application Vendors (include web site owners) and Application Users (including average Joe with a web browser). Is it fair that Vendors would get advanced notice to patch their systems before Users even know a problem exists? Furthermore, is it fair that only a select group of Vendors would be given that notice? I don't really believe so.

      I can see how the entity who discovered the issue would selfishly patch their own systems before releasing it. I get it. But the responsible thing to do after that has got to be disclosing to the upstream vendor. Is 11 days the length of time it took to update Google's entire infrastructure? They're a strange beast, and that would be quite impressive if so, particularly on non-linux systems where package management/creation is a little less friendly. Either way, given their size, I can't honestly fault them for 11 day disclosure to OpenSSL. I can fault them for disclosing to their friends first.

      --
      Squash
  9. CISSP opinion: the patch proves Google f***ed up by xxxJonBoyxxx · · Score: 1

    >> Google notified OpenSSL about the bug on April 1 in the US – at least 11 days after discovering it.

    "OK, maybe it was caught up in legal. Suits at large corporations can take a while."

    >> Google would not reveal the exact date it found the bug, but logs show it created a patch on March 21,

    "On second thought, if the geeks on the ground had the authority to patch and roll to production, then why the finger to the Open Source community, Google?"

  10. Issue? by silanea · · Score: 5, Insightful

    What exactly is the issue here? Maybe I misread TFS and the linked articles, but as I understand the chief complaint - apart from Google's delay in reporting to OpenSSL - is that some large commercial entities did not receive a notification before public disclosure. I did not dig all too deep into the whole issue, but as far as I can tell OpenSSL issued their advisory in lieu with a patched version. What more do they expect? And why should "Cisco[,] Juniper[,] Amazon Web Services, Twitter, Yahoo, Tumblr and GoDaddy" get a heads-up on the public disclosure? I did not get a heads-up either. Neither did the dozens or so websites not named above that I use. Neither did the governmental agency I serve with. Nor the bank whose online-banking portal I use. Are we all second-class citizens? Does our security matter less simply because we provide services to fewer people, or bring lower or no value to the exchange?

    A bug was reported, a fix was issued, recommendations for threat mitigation were published. There will need to be consequences for the FLOSS development model to reduce the risk for future issues of the sort, but beyond that I do not quite understand the fuss. Can someone enlighten me please?

    --
    Rudolf Hess edited Mein Kampf. He was the very first grammar nazi.
    1. Re:Issue? by Anonymous Coward · · Score: 0

      Does our security matter less simply because we provide services to fewer people

      Yes. That is all.

      Was that so hard to understand?

    2. Re:Issue? by Anonymous Coward · · Score: 0

      but as I understand the chief complaint - apart from Google's delay in reporting to OpenSSL - is that some large commercial entities did not receive a notification before public disclosure

      I don't really care about those commercial entities. For me its all about OpenSSL knowing. The fact that they and the big distros didn't have a new package ready to roll the second this went public is everything I need to know to call this "disclosure" a clusterfuck.

    3. Re:Issue? by Anonymous Coward · · Score: 0

      OpenSSL should have been the first party to receive a resport of the disclosure, I mean that's where the patch needs to go to fix it and they could have yanked any binaries that default to using Heartbeat until it was fixed.

      This is pretty much irresponsible disclosure, notify your friends, but not the people who actually produce the software and to hell with anybody else that integrates the software in their product. This is one of the downsides to OSS, since people can patch things like this on their own, they can patch their shit silently before notifying people that they need a patch for it.

  11. Re:Not that good by Opportunist · · Score: 3, Insightful

    Would you put your life on closed source software not having any bugs that we just don't know about because it's closed source and hence can NOT be reviewed sensibly?

    Closed source and open source share one problem: Both can and will have bugs. Open source only has the advantage that they will be found and published. In closed source, usually NDAs keep you from publishing anything you might come across, ensuring that knowledge about these bugs stays within certain groups that have a special interest in not only knowing about it but abusing them.

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  12. wtf ? by Tom · · Score: 3, Interesting

    IT security industry experts are beginning to turn on Google and OpenSSL, questioning whether the Heartbleed bug was disclosed 'responsibly.

    Are you fucking kidding me? What kind of so-called "experts" are these morons?

    Newflash: The vast majority of 0-days are known in the underground long before they are disclosed publicly. In fact, quite a few exploits are found because - drumroll - they are actively being exploited in the wild and someone's honeypot is hit or a forensic analysis turns it up.

    Unless you have really, really good reasons to assume that this bug is unknown even to people whose day-to-day business is to find these kinds of bugs, there is nothing "responsible" in delaying disclosure. So what if a few script-kiddies can now rush a script and do some shit? Every day you wait is one day less for the script kiddies, but one day more for the real criminals.

    Stop living in la-la-land or in 1985. The evil people on the Internet aren't curious teenagers anymore, but large-scale organized crime. If you think they need to read advisories to find exploits, you're living under a rock.

    --
    Assorted stuff I do sometimes: Lemuria.org
    1. Re:wtf ? by Anonymous Coward · · Score: 0

      Real criminals and governments, that is. But I repeat myself.

    2. Re:wtf ? by jones_supa · · Score: 2

      Newflash: The vast majority of 0-days are known in the underground long before they are disclosed publicly. In fact, quite a few exploits are found because - drumroll - they are actively being exploited in the wild and someone's honeypot is hit or a forensic analysis turns it up.

      It's not that black and white. You expose the vulnerability to even more crackers if you go shouting it around like was done here.

    3. Re:wtf ? by MrL0G1C · · Score: 3, Insightful

      As an end-user I'm glad it was shouted about because it gave me the chance to check that any software that could affect me financially was updated or invulnerable.

      So, can you tell me why I shouldn't be notified?

      --
      Waterfox - a Firefox fork with legacy extension support, security updates and better privacy by default.
    4. Re:wtf ? by jones_supa · · Score: 1

      Because the vulnerability was in the server side.

    5. Re:wtf ? by gman003 · · Score: 1

      Yes, which is why the best compromise is a private disclosure to whoever can *fix* the bug, followed by a public announcement alongside the fixed release. That limits the disclosure to the minimum necessary while the flaw is unfixed.

    6. Re:wtf ? by Anonymous Coward · · Score: 0

      The vulnerability was in the server side of all servers using OpenSSL*. That includes an enormous number of home servers in addition to large commercial ones. Should their admins not be notified?

      * Not to mention all the end-user products using OpenSSL

    7. Re:wtf ? by Tom · · Score: 1

      There's a black market where you can buy and sell 0-days.

      Sure you give it to more people (and for free) than before. But the really dangerous people are more likely than not to already have it.

      --
      Assorted stuff I do sometimes: Lemuria.org
    8. Re:wtf ? by Tharkkun · · Score: 1

      Newflash: The vast majority of 0-days are known in the underground long before they are disclosed publicly. In fact, quite a few exploits are found because - drumroll - they are actively being exploited in the wild and someone's honeypot is hit or a forensic analysis turns it up.

      It's not that black and white. You expose the vulnerability to even more crackers if you go shouting it around like was done here.

      So a few crackers start exploiting basic websites yet the responsible admins have already disabled or patched their affected websites. No ones afraid of some stupid kids but the underground mafia, such as the ones who stole data from Target are the threat.

    9. Re:wtf ? by Anonymous Coward · · Score: 0

      And you know he isn't running any of his own servers how?

    10. Re:wtf ? by Tom · · Score: 1

      There's a difference?

      --
      Assorted stuff I do sometimes: Lemuria.org
  13. are we seriously blaming google by Anonymous Coward · · Score: 1

    and not NSA who found the bug 4 years ago when the bug was first introduced?

    1. Re:are we seriously blaming google by xxxJonBoyxxx · · Score: 4, Insightful

      >> are we seriously blaming google and not NSA who found the bug 4 years ago when the bug was first introduced?

      Yes. The NSA is the US gov's lead black hat. Google's an advertising company that depends on people trusting the Internet for information and commerce. I'd expect the NSA to hoard information to assist their black-hatting, and I'd expect Google to quickly share anything they know so security vulnerabilities can be patched and people don't lose faith in the Internet*.

      * = (Seriously, when people have asked me what to do about Heartbleed, I've said "don't buy anything you don't need, and try to avoid paying any bills online or doing any online checking for a week or two - then change your password as soon as you sign on.")

    2. Re:are we seriously blaming google by Anonymous Coward · · Score: 0

      Indeed, the really tricky part about OSS is that all vulnerabilities are handed on a silver platter to NSA, without them ever telling us what they might have found.

      I wouldn't be surprised if NSA knows more backdoors to OSS stuff than to closed source software. It takes them much less effort to analyze the source than machine language code.

  14. Re:Not that good by Nemesisghost · · Score: 3, Interesting

    Open source software is often made freely available at no costs to downloaders and embedders. There is little incentive for these users to pay anything for it, including for support, since the main reason to adopt this software is to not pay at all.

    Well, one could hope that issues like this will prompt those selfish companies to begin either developing their own software & quit relying on the freely given work of others or give them an incentive to support those who are building the critical software components. My personal opinion is that if a company is going to utilize a FOSS project and do self support, that they would provide some sort of resource back to the project.

    Further aggravating the issue is the claim by activists that the software code is reviewed by millions of people as it is freely available to anyone. The fallacy of this claim resides in the lack of interest of anyone to do this. Indeed, who would review other people's code for free or for fun?

    I happen to know several people who like reviewing & examining other people's code, especially complex code like what one would find in OpenSSL. These are the same type of people who just so happen to be the ones fixing a lot of the bugs you run into in OSS projects. It is people like that who make OSS projects succeed. I mean Linus Torvalds wrote Linux as a hobby project, and continued to review people's additions as a part of that hobby(now he gets paid to do what he was doing for fun). I personally don't do it because my free time interests lie elsewhere, but I enjoy software development enough that I would without those other distractions. So I'd say your argument is invalid.

  15. Re:Not that good by Tom · · Score: 3, Interesting

    Several fundamental mistakes in there.

    First, OpenSSL is not typical of Free Software. Cryptography is always hard, and other than, say, an Office Suite, it will often break spectacularily if a small part is wrong. While the bug is serious and all, it's not typical. The vast majority of bugs in Free Software are orders of magnitude less serious.

    Second, yes it is true that the notion that anyone can review the source code doesn't mean anyone will actually do it. However, no matter how you look at it, the number of people who actually do will always be equal or higher than for closed source software.

    Third, the major flagships of Free Software are sometimes, but not always picked for price. When you're a fortune-500 company, you don't need to choose Apache to save some bucks. A site-license of almost any software will be a negliegable part of your operating budget.

    And, 3b or so, contrary to what you claim, quite a few companies contribute considerable amounts of money to Free Software projects, especially in the form of paid-for support or membership in things like the Apache Foundation. That's because they realize that this is much cheaper than having to maintain a comparable software on their own.

    --
    Assorted stuff I do sometimes: Lemuria.org
  16. Re:Not that good by jones_supa · · Score: 2

    Open source only has the advantage that they will be found and published. In closed source, usually NDAs keep you from publishing anything you might come across, ensuring that knowledge about these bugs stays within certain groups that have a special interest in not only knowing about it but abusing them.

    That doesn't still automatically mean that closed source fares worse in found bugs. Companies often have quite bad-ass internal quality assurance measures. They have money to put in it and, it actually produces them value. There is an incentive to do it properly. Of course the tools and methodologies vary from company to company. But let's take Microsoft: they have very rigorous code quality standards and very thorough code audits, before anything gets out from the house.

    Sure, we can have lots of eyeballs scanning open source code, but there is no guarantee that a quantified amount of review ever happens. That's really, really bad.

  17. One Cyberneticist's Ethics by VortexCortex · · Score: 2

    Once again the evil of Information Disparity rares its ugly head. To maximize freedom and equality entities must be able to decide and act by sensing the true state of the universe, thus knowledge should be propagated at maximum speed to all; Any rule to the contrary goes against the nature of the universe itself.

    They who seek to manipulate the flow of information wield the oppression of enforced ignorance against others despite their motive for doing so. The delayed disclosure of this bug would not change the required course of action. The keys will need to be replaced anyway. We have no idea whether they were stolen or not. We don't know who else knew about this exploit. Responsible disclosure is essentially lying by omission to the world. That is evil as it stems from the root of all evil: Information Disparity. The sooner one can patch their systems the better. I run my own servers. Responsible disclosure would allow others to become more aware than I am. Why should I trust them not to exploit me if I am their competitors or vocal opponent? No one should decide who should be their equals.

    Fools. Don't you see? Responsible disclosure is the first step down a dangerous path whereby freely sharing important information can be outlawed. The next step is legislation to penalize the propagators of "dangerous" information, whatever that means. A few steps later will have "dangerous" software and algorithms outlawed for national security, of course. If you continue down this path soon only certain certified and government approved individuals will be granted license to craft certain kinds of software, and ultimately all computation and information propagation itself will be firmly controlled by the powerful and corrupt. For fear of them taking a mile I would rather not give one inch. Folks are already in jail for changing a munged URL by accident and discovering security flaws. What idiot wants to live in a world where even such "security research" done offline is made illegal? That is where Responsible Disclosure attempts to take us.

    Just as I would assume others innocent unless proven guilty of harm to ensure freedom, even though it would mean some crimes will go unpunished: I would accept that some information will make our lives harder, some data may even allow the malicious to have a temporary unfair advantage over us, but the alternative is to simply allow even fewer potentially malicious actors to have an even greater power of unfair advantage over even more of us. I would rather know that my Windows box is vulnerable and possibly put a filter in my IDS than trust Microsoft to fix things, or excuse the NSA's purchasing of black-market exploits without disclosing them to their citizens. I would rather know OpenSSL may leak my information and simply recompile it without the heartbeat option immediately than trust strangers to do what's best for me if they decide to not do something worse.

    There is no such thing as unique genius. Einstein, Feynman, and Hawking, did not live in a vacuum; Removed from society all their lives they'd have not made their discoveries. Others invariably picked up from the same available starting points and solve the same problems. Without Edison we would still have electricity and the light bulb. Without Alexander Bell we would have had to wait one hour for the next telephone to enter the patent office. Whomever discovered this bug and came forward has no proof that others did not already know of its existence.

    Just like the government fosters secrecy of patent applications and reserves their right to exclusive optioning of newly patented technology, if Google had been required keep the exploit secret except to government agencies we may never have found out about heartbleed in the first place. Our ignorance enforced, we would have no other choice but to keep our systems vulnerable. Anyone who thinks hanging our heads in the noose of responsible disclosure a good idea is a damned fool.

    1. Re:One Cyberneticist's Ethics by Anonymous Coward · · Score: 0

      Did you seriously just call yourself a "Cyberneticist"?

  18. Public-facing disclosure by simplypeachy · · Score: 1

    The real scandal is how organisations are giving information to their users as to how they are affected and what users should do. Many big-name companies are using very specific phrasing such as "key services were not vulnerable", but no mention of secondary services...sounds like a liar's hiding place to me. There are also far too many who don't understand the problem such as Acronis, the Aus bank etc. Then the likes of Akamai who can't make their mind up. Some irresponsibly down-playing the whole thing and of course, the majority of the rest who haven't said sweet FA. In the middle are the poor people who can't be expected to make informed decisions on what they need to do or how exposed they are.

    You thought rfc-ignorant, abuse@ ignoring fuckwits, running their company around the Internet with Flash-only sites was bad? This is what happens when their incompetence starts to actually harm people's online security.

  19. Blame Game. by jellomizer · · Score: 4, Insightful

    That is the biggest problem. Other then rewarding the people who fix the problem, we try to figure out who is to blame for every freaking thing.

    Oh look a flood hit the city unexpected, well lets blame the mayor for not thinking about this unexpected incident.

    Or a random guy blew up something, why didn't the CIA/NSA/FBI know that he was doing this...

    We are trying to point blame on too many things, and less time trying to solve the problem.

    --
    If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    1. Re:Blame Game. by Fnord666 · · Score: 1

      That is the biggest problem. Other then rewarding the people who fix the problem, we try to figure out who is to blame for every freaking thing.

      "Fix the problem, not the blame."
      Rising Sun (1993) - Capt. John Connor (Sean Connery)

      --
      'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
    2. Re:Blame Game. by andydouble07 · · Score: 0

      Better than blaming blaming Bush for everything for everything.

    3. Re:Blame Game. by ustolemyname · · Score: 1

      Or a random guy blew up something, why didn't the CIA/NSA/FBI know that he was doing this...

      If those organizations are going to continue receiving more money, more privilege, and less oversight in the name of protecting us from terrorists, then they deserve blame when they have nothing to show for what they have taken from us.

    4. Re:Blame Game. by Anonymous Coward · · Score: 0

      The more effective the pointing finger for 'blame', the more radical the 'solution'. Radical solutions tend to be like the Bush admin, taking people's freedom permanently for short term results. The baneful effects, for instance, of spying on our own population and then the whole world's people (secretly at first until the secret got out as these always will....Trotsky said that) are now belatedly setting in. Soon the 'tea party' will pay the price along with the whole republican party. It will be a good catharsis to get back to our roots in free society ...free of willful grubby spies. We do not need a home grown KGB making life miserable for everyone. Even Russia got rid of the KGB....yeah they got the FRS but it is like our old FBI minus Hoover the panty sniffer.

  20. Commercial decision by Google by Anonymous Coward · · Score: 0

    Selective leaks to friends, screw over the competitors.

    They've set the precedent now - time to sit back and watch them get burned by it in the future.

  21. WRONG by doas777 · · Score: 1

    If this hadn't been publicly disclosed, it would have just gone into the 0-day libraries which Intelligence agencies around the globe have been amassing. We'd never learn we were vulnerable, and their ability to impersonate and eavsdrop would have increased beyond any reasonably-articulatable expectation.

    Responsible disclosure to sufficient parties to address the issue would also expose it to potential attackers, and there will always be players with need-to-know who won't be identified for notification.

  22. Needless subject by Anonymous Coward · · Score: 0

    The fact that OpenSSL is open source and had a trivial mistake that exposed the entirety of the Internet's encrypted traffic to easy eavesdropping for years should be a clue to how trustworthy open source software can be.

    1. Re:Needless subject by Opportunist · · Score: 3, Insightful

      The whole point of OSS is that I do not need to trust it. I can review it if I please.

      Trustworthiness is only a matter with closed source. Because there all I can really do is trust its maker.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  23. Blame Game by Anonymous Coward · · Score: 0

    This is a common and well known americanism related to a complex interaction between hierarchal socialism, legality, and the fact you westerns seem to think the best way to repent for making mistakes is to dump it all on someone else either by means of blame or legal charges (most commonly in ameica in the form of suing others). Good luck changing that.

    In the east people gain face by solving problems succinctly and gracefully, without making the kind of fuss westerners do when something goes wrong. As opposed to finding ways to make others lose face because they made a mistake.

    This could probably also be summed up as a comparison of authoritarianism (west focuses on self and power) vs. communism (east focuses on the big picture and the community)

    1. Re:Blame Game by jemmyw · · Score: 1

      Yeah I don't think the East is any better than West in this area. Communism focuses on the big picture and community? What, by pretending problems don't exist, denying they exist, waiting for a catastrophe and then accepting the blame, but oh well it's too late, and by the way we're the all powerful communist party, don't even think about criticizing us?

    2. Re:Blame Game by jellomizer · · Score: 1

      Well at least in the west we actually state that there is a problem. In eastern cultures there is too much ignoring that there is even a problem.

      There is nothing wrong about making a fuss about a problem. But after we make the fuss you need to do something to fix it.
      Not making a fuss about it makes it too easy to hide away.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
  24. Doesn't ANYONE get it??? by marienf · · Score: 1

    > and not as late as it did on April 1

    That must have been the most expensive April Fool's joke EVER.

    -f

  25. "the underground" by Anonymous Coward · · Score: 0

    Are you fucking kidding me? What kind of so-called "experts" are these morons?

    Newflash: The vast majority of 0-days are known in the underground long before they are disclosed publicly.

    But "the underground" is not some monolithic entity. It's spread out over the entire planet and over tens (hundreds?) of thousands of people. Some may know about a particular exploit and some may not. Once you announce it however, everyone does know it.

    So by allowing the vendor 1-2 weeks to issue a patch, you contain the exploit from being used by 100% of "the underground", to 'only' 0.001/1/2/5/7/10/33/whatever percent. If there's only a dozen guys in the Republic of Elbonia that know it, that's different then the entire Russian mafia and/or the Chinese cyber-army knowing.

    Scale matters.

    1. Re:"the underground" by Tom · · Score: 1

      That is true. However, you also need to take a few other things into account. I'll not go into detail, I think everyone has enough knowledge and imagination to fill in the blanks:

      • There is an actual black market for exploits where they are bought and sold.
      • Not announcing a weakness withholds the information not just from the bad guys, but also from sysadmins, preventing mitigating measures and proper risk awareness.
      • We have over 20 years of history proving that vendors regularily move slower or not at all until a weakness is making headlines
      • There have been many cases where several researchers had partial information about an exploit, and only once combined was the true impact known. For example, one research might know about the problem and how to exploit it, but thinks it can't be leveraged to a compromise. Another might know about the potential compromise, but think it can't be triggered in a real-world scenario.

      Despite all the theoretical arguments seemingly in favour, security through obscurity does not work and we've known that for like forever.

      --
      Assorted stuff I do sometimes: Lemuria.org
  26. What by Anonymous Coward · · Score: 0

    However, no matter how you look at it, the number of people who actually do will always be equal or higher than for closed source software.

    Upon what data is this assumption based? How many people have reviewed the code behind Microsoft's BitLocker vs. how many have reviewed the code for TrueCrypt, for example? The real question is how many QUALIFIED people are reviewing the code. In the case of OpenSSL it appears the answer was ONE (and they missed a trivial mistake).

    1. Re:What by Tom · · Score: 1

      See other reply.

      Yes, of course, a closed source development that does external code reviews can have more eyes on the project then an open source development that does no external code reviews. But then you're comparing apples and oranges.

      --
      Assorted stuff I do sometimes: Lemuria.org
  27. Global release is preferable. by Kremmy · · Score: 1

    The only thing you do by hiding this kind of information is limit the number of heads working to fix it. I'm tired of these attempts at plugging the hole in the dam by pretending the hole isn't there until someone plugs it.

  28. Full disclosure, nothing else by allo · · Score: 1, Interesting

    Look, Google knew it. Google is part of prism. You are still wondering, if the NSA may have used Heartbleed?

  29. Why free and fun? I review FOSS for a living. by raymorris · · Score: 3, Informative

    > Indeed, who would review other people's code for free or for fun?

    Some people do, of course. I have, specifically for security issues, because that's a major resume point in the security world - having actually found and fixed real-world security issues.

    99% of the time, I'm being paid to review and improve open source code. All of those companies that use open source, including Google, have a vested interest in making sure that the code they use is good. Since it's open source, the Google techs can actually dig into the code and find issues like this, then fix it, just like they did in this case. They didn't do it for free and for fun, they did it because Google relies on OpenSSL.

    My employer also relies on OSS. My job is to administer, maintain, and improve the OSS software we use. I've found and fixed security issues. Not for free and for fun, but because we want our systems to be secure, and having the source allows me to do that.

    When I craft an improvement, at LEAST three people have to look at it before it's committed upstream. Typically, five or six people will comment on it and suggest improvements or state their approval before it's finalized.

  30. Certainly semi-public state is the worst by iamacat · · Score: 1

    Once the discoverer of the bug patched their own servers and the software creator has an official fix, the only ethical thing is to tell everyone at once. It is not realistic to expect a secret to be kept in a dozen independent companies with thousands of employees each. Also, why should Facebook get an unfair business advantage over Yahoo? Most users having dozens of accounts where overlapping private information is stored and get no benefit from just one server being patched.

    Make sure a fix is available and then publish quickly so that bad actors have less time to develop exploits.

  31. Re:Not that good by Opportunist · · Score: 2

    Sorry, but no. Just because it produces them revenue doesn't mean they have an incentive to do it properly. They have an incentive to do it good enough that people buy it. That does not necessarily mean that the software is of high quality.

    What is necessary to this end is that the software appeals to decision makers. They are rarely if ever the same people that are by any means qualified to assess the technical quality of code.

    For reference, see SAP.

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  32. We protected 1 billion people by notifying trusted by raymorris · · Score: 2

    This was handled similarly to a flaw I discovered, and I think it makes sense. Facebook, for example, has about a billion users. If you have a colleague you trust at Facebook, informing that one colleague can protect Facebook's billion users.

    The risk is of a leak before a fix is widely deployed is dependent on a) the number of people you inform and b) how trustworthy those people are to keep quiet for a couple of days. It's quite reasonable to minimize the risk of a leak by keeping it low profile for a few days, while minimizing the damage by protecting as many people as possible.

    For CVE-2012-0206 , developers knew that wikimedia was the largest user. Wikipedia and related properties account for over half the the end-users that could be affected. So by letting just one person know about it ahead of time, we could protect millions of wikipedia users. That seems like a good trade, so we let wikipedia have the patch 24 hours before the main distros like Red Hat put the patch out publicly and the vulnerability became well known. Nobody was harmed by hearing about it on Tuesday rather than on Monday, and all of wikipedia's users were protected from being affected by keeping it secret for a day while wikipedia's servers were patched.

  33. Re:Not that good by Zero__Kelvin · · Score: 1

    ". Companies on rare occassion have quite bad-ass internal quality assurance measures. "

    FTFY (Have you ever worked at any actual companies?)

    --
    Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  34. Actual Experience Against "Responsible Disclosure" by DERoss · · Score: 4, Interesting

    Historically, so-called "responsible disclosure" has resulted in delayed fixes. As long as the flaw is not public and causing a drum-beat of demands for a fix and a possible loss of customers, the developer organization too often treats security vulnerabilities the same as any other bug.

    Worse, those who report security vulnerabilities responsibly and later go public because the fixes are excessively delayed often find themselves branded as villains instead of heroes. Consider the case of Michael Lynn and Cisco in 2005. Lynn informed Cisco of a vulnerability in Cisco's routers. When Cisco failed to fully inform its customers of the significance of the security patch, Lynn decided to go public at the 2005 Black Hat conference in Las Vegas. Cisco pressured Lynn's employer to fire him and also filed a lawsuit against Lynn.

    Then there was the 2011 case of Patrick Webster, who notified the Pillar Administration (major administrator of retirement plans in Australia) of a security vulnerability in their server. When the Pillar Administration ignored Webster, he used the vulnerability to extract personal data from about 500 accounts from his own pension plan (a client of the Pillar Administration). Webster made no use of the extracted personal data, did not disseminate the data, and did not go public. He merely sent the data to the Pillar Administration to prove the existence of the vulnerability. As a result, the Pillar Administration notified Webster's own pension plan, which in turn filed a criminal complaint against Webster. Further, his pension plan then demanded that Webster reimburse them for the cost of fixing the vulnerability and sent letters to other account holders, implying that Webster caused the security vulnerability.

    For more details, see my "Shoot the Messenger or Why Internet Security Eludes Us" at http://www.rossde.com/editoria....

  35. Re:Not that good by suutar · · Score: 1

    Indeed, who would review other people's code for free or for fun?

    Well, right offhand, Coverity will. They're not perfect, of course, but they're pretty good. Their system didn't flag Heartbleed, but Heartbleed showed them how they could add a new test that would and that has reportedly found other possible issues, which are being investigated and will either be fixed or found to be false positives and used to refine the new test. Either way, not a bad thing.

  36. No. by drolli · · Score: 1

    If i find a bug which is critical to my employer while being plaid by my employer, the first and only thing which is do is assess the impact to my emplyer, and identify the most important measures for the employers business.

    IMHO they acted correctly: protect your own systems, and then the systems with the biggest impact.

  37. But what if someone *is* harmed by the delay? by Anonymous+Brave+Guy · · Score: 1

    Nobody was harmed by hearing about it on Tuesday rather than on Monday

    Isn't that assumption where the whole argument for notifying selected parties in advance breaks down?

    If you notify OpenSSL, and they push a patch out in the normal way, then anyone on the appropriate security mailing list has the chance to apply that patch immediately. Realistically, particularly for smaller organisations, it will often be applied when their distro's mirrors pick it up, but that was typically within a couple of hours for Heartbleed, as the security and backporting guys did a great job at basically all of the main distros on this one.

    As soon as you start picking and choosing who else to tell first, yes, maybe you protect some large sites, but those large sites are run by large groups of people. For one thing, they probably have full time security staff who will get the notification as soon as it's published, understand its significance, and act on it immediately. For another thing, they probably have good automated deployment systems that will systematically patch all their affected servers reliably and quickly.

    (I accept that this doesn't apply to those who have products with embedded networking software, like the Cisco and Juniper cases. But they can still issue patches to close the vulnerability quickly, and the kinds of people running high-end networking hardware that is accessible from outside a firewall are also probably going to apply their patches reasonably quickly.)

    On the flip side, as long as you're giving advance warning to those high profile organisations, you're leaving everyone else unprotected. In this case, it appears that at least two different parties identified the vulnerability within a few days of each other, but the vulnerability had been present for much longer. There is no guarantee that others didn't already know about it and weren't already exploiting it. In general, though it may not apply in this specific case, if some common factor prompted the two contemporaneous discoveries, it might well be the case that additional, hostile parties have found it around the same time too.

    In other words, you can't possibly know that nobody was harmed by hearing about it a day later. If a hostile party got hold of the vulnerability on the first day, maybe prompted by whatever also caused the benevolent parties to discover it or by some insider information, then they had a whole day to attack everyone who wasn't blessed with the early knowledge, instead of a couple of hours. This is not a good thing.

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  38. Re:We protected 1 billion people by notifying trus by sabri · · Score: 1

    This was handled similarly to a flaw I discovered, and I think it makes sense. Facebook, for example, has about a billion users. If you have a colleague you trust at Facebook, informing that one colleague can protect Facebook's billion users.

    Ah yes, the duckface pictures of a bunch of teens are way more important than, let's say, millions of tax returns.

    --
    I'm not a complete idiot... Some parts are missing.
  39. False sense of security by Anonymous+Brave+Guy · · Score: 1

    The whole point of OSS is that I do not need to trust it. I can review it if I please.

    But you didn't review it and find the vulnerability, did you?

    And apparently, despite the significance and widespread use of this particular piece of OSS, for a long time no-one else did either, or at least no-one who's on our side did.

    Your argument is based on theory. The AC's point is based on pragmatism. It's potentially an advantage that OSS can be reviewed by anyone, but a lot of the time that gives a false sense of security. What matters isn't what could happen, it's what actually does happen.

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    1. Re:False sense of security by Opportunist · · Score: 2

      What I really don't like about the whole statement behind it is the implied assumption that closed source offered any kind of better protection.

      You know what's the main difference between an OSS and a CSS audit? That I can't go "hey, psst, take a look at $code. Maybe you see something interesting..." to you when I find something in CSS software and someone in a badly fitting suit tells me to shut up about it.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    2. Re:False sense of security by Anonymous+Brave+Guy · · Score: 1

      What I really don't like about the whole statement behind it is the implied assumption that closed source offered any kind of better protection.

      Which statement do you think implied that? I don't see anything about it in this thread.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    3. Re:False sense of security by Opportunist · · Score: 1

      There are exactly two possible ways you can handle your source code: You can keep it secret or you can publish it. Everything else is only a variant of either.

      So if you claim one of them offers bad security protection, you imply that the other one offers a better one.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  40. I don't trust "secret circles" by WaffleMonster · · Score: 1

    This is foolish when you apply a patch to an open source project it essentially becomes public knowledge to anyone who is paying attention at that point. The more you do this the more eyes on patches. This only yields ignorance and suppresses urgency.

    Only telling a select few (normally by subscription to very expensive security services) gives giant media an advantage it is not clear to me they have a right to or in any way deserve.

    Finally as much money locked up in black/gray hat activities we don't need to be enriching anyone for contributing to an industry of an elite few none of us have any reason to trust.

    Behavior of crowd at recent BlackHat toward Mr. Alexander made crystal clear to me kids have all grown up and money runs the show now. The more money the more "ethics" bend towards production of additional money.

  41. Re:Not that good by Anonymous+Brave+Guy · · Score: 1

    However, no matter how you look at it, the number of people who actually do will always be equal or higher than for closed source software.

    Why? I see little evidence that this is happening in general.

    Most established OSS projects seem to require no more than one or two reviewers to approve a patch before it goes in, and then there is no guarantee that anyone will ever look at that code again later.

    How does that guarantee that more experts will review a given piece of security code than in a proprietary, closed-source, locked-up development organisation that also has mandatory code reviews?

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  42. Re:We protected 1 billion people by notifying trus by Anonymous Coward · · Score: 0

    Nobody was harmed by hearing about it on Tuesday rather than on Monday

    Are you absolutely sure about that? Completely positive?
    I suspect more than zero people were if not harmed then defiantly harmed further by such a situation.

    Yes, you can easily marginalize the small percentage of people who were exploitable by black hats for 371 days instead of only 370 days as the case was, but just because 1/370 is a small fraction doesn't mean it is zero - people attacked using this exploit in the prior 370 days to Google announcing it would certainly disagree with you about the number of days notice they got - and the 1/370 percentage of people being exploited either again or for the first time on that last day would also disagree with you.

    Remember, just because it was first discovered by the white hats at Google just this year does NOT mean this exploit wasn't being actively exploited in the underground for hundreds of days already - because they were.

  43. Next up: customer notification by Just+Some+Guy · · Score: 1

    One thing I haven't heard discussed is whether affected companies should be notifying their end users about whether they were affected and when it was fixed. I haven't heard from my bank, for example. Where they ever vulnerable? Should I update my password? If they were vulnerable, is it fixed now or would I just be handing an attacker my new password if I were to reset it today?

    I wrote up a proposal called Heartbleed headers for communicating this information to site visitors. While I'd like it if everyone picked my idea as the new standard way for doing this, I just wish admins would start using something. We're so close to having a browser plugin be able to tell you "you need to update your password on this site" as you browse. How nice would that be?

    --
    Dewey, what part of this looks like authorities should be involved?
  44. Re:Not that good by Tom · · Score: 1

    I didn't see it's the thousands of eyes that fanatics claim.

    I'm simply saying that if your source code is open, your number of eyes on the project is (dev team) + (people looking at it) while for a closed source project the number is (dev team).

    Since "people" cannot be negative, by necessity (dev team) + (other people) >= (dev team)

    How does that guarantee that more experts will review a given piece of security code than in a proprietary, closed-source, locked-up development organisation that also has mandatory code reviews?

    It doesn't.

    It does guarantee that the number of reviewers is equal to or higher, provided everything else is equal.

    --
    Assorted stuff I do sometimes: Lemuria.org
  45. Wrong math. 2 years of vulnerability. by raymorris · · Score: 3, Insightful

    > they had a whole day to attack everyone who wasn't blessed with the early knowledge, instead of a couple of hours

    Years, not hours. Assuming the bad guys knew about it, they had two YEARS to attack people. If we told people that there was an issue on Monday, that doesn't protect them - they just know that their vulnerable. They couldn't do anything about it until the update packages were available on Tuesday.

    On the other hand, had we made it public on Monday, we would have GUARANTEED that lots of bad guys knew about it, during a period in which everyone was vulnerable.

    I'm talking about what we did here. It appears to me that Google definitely screwed up by not telling the right people on the OpenSSL team much sooner. (Apparently they told _someone_ involved with OpenSSL right away, but not the right soemone.)

    > you protect some large sites, but those large sites are run by large groups of people. For one thing, they probably have full time security staff who will get the notification as soon as it's published, understand its significance, and act on it immediately.

    ROTFL. Yep, large corporate bureaucracies, they ALWAYS do exactly the right thing, in a matter of hours.

    1. Re:Wrong math. 2 years of vulnerability. by Anonymous+Brave+Guy · · Score: 1

      You're latching onto this specific case, perhaps because you have some connection to it, but I'm talking about the general principle here. In general, it is not unreasonable to assume that if a vulnerability has been found by two parties in rapid succession, there may be a common factor involved, which may mean that other parties will also find it in the same time frame, and that an extra day may therefore be very significant.

      Obviously most serious security bugs don't sit there for years, then have two groups discover them at almost the same time, as seems to have happened in this case, and need half the known Internet to update their systems as a precaution because no-one really knows whether they've been damaged by the vulnerability at any time over the past couple of years.

      ROTFL. Yep, large corporate bureaucracies, they ALWAYS do exactly the right thing, in a matter of hours.

      If it's that funny to you, why are you defending giving them a day of advanced warning? Some of us did have a patch rolled out within a couple of hours of the public announcement, but presumably we could have had the patch rolled out a day earlier in the alternative situation. Once again, in this case, one day in two years obviously isn't that significant as we're all going to have to assume keys were compromised and set up new ones anyway. But if this was something that only got committed three days ago, it's a different story.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  46. PS: how do you think it gets on the distro mirror? by raymorris · · Score: 1

    > Isn't that assumption where the whole argument for notifying selected parties in advance breaks down? ...
    > it will often be applied when their distro's mirrors pick it up, but that was typically within a couple of hours for Heartbleed

    How do you think those packages get on the mirrors? Do their servers magically patch the code, rebuild the packages, and set it as a high priority update? The fix gets on the mirrors as a result of "notifying selected parties in advance".

  47. Nothing can protect those tax returns, only endang by raymorris · · Score: 1

    There is no option that's going to protect those tax returns. Telling the bad guys about it will certainly endanger the tax return data, though.
    Since many (most?) people use the same or similar password for Facebook as they use for their tax service, protecting Facebook traffic actually protects a few tax returns.

    What clearly isn't an effective option would be to announce the vulnerability to hundreds of tax-preparer sites before a updated package is available, expecting them to manually (and correctly) patch the code, without leaking the vulnerability so that it becomes widely known to the bad guys.

    If you're going to try to protect people in the time between discovery and the fix being widely distributed, you can only do that by keeping it relatively secret, by limiting details to a small number of trusted people. Once you tell a lot of people, you've told a lot of bad guys. There's no need to do that before the updates are available and people can protect their customers.

  48. Developer First - then Cyber Security groups by Anonymous Coward · · Score: 0

    Contact the developers first, let them know that they need to notify the security groups by a certain date as you will be doing so as well on that date.

    If they notify first, great, if not, then you know they chose not to, and it's good that you did.

  49. same thing by simishag · · Score: 1

    I'd say you follow the same process: inform them, wait 1/3/7 days or whatever, then go public. If you suspect the exploit is deliberate, informing the manufacturer isn't telling them anything they didn't already know. Or, maybe it IS telling them, since in the case of open source, the exploit could have been introduced surreptitiously by a developer who's long gone, and the current developers have no idea of the exploit's existence.

    Caveat: if you suspect revealing the bug will cause blowback to you. If you think the NSA/FBI/CIA will come after you for threatening to reveal it, I'd say just go public immediately, and include major press orgs so they can't just silence you.

  50. Re:Not that good by dkf · · Score: 1

    A site-license of almost any software will be a negliegable part of your operating budget.

    It depends on what the software is. Some things are genuinely expensive, enough that while maybe a Fortune 500 can handle it, the many smaller companies out there tend to swoon at the prices charged. (These pieces of software tend to be in areas without major OSS competition.)

    --
    "Little does he know, but there is no 'I' in 'Idiot'!"
  51. Nonsense Nonsense Nonsense by gelfling · · Score: 1

    I'm in outsourcing and our #1 problem this week by far is getting clients to actually allow us to patch their shit.

  52. Re:Not that good by Anonymous Coward · · Score: 0

    I wrote the OP in a trollish manner, the last line anyway is troll but the rest is true. I'm into OSS, btw, and your statement is mathematically correct. But I hate the "thousands eyeballs" claim, which is false, and this trivial OpenSSL (my sincere sympathies to the developer) is the epitome of this false security because OpenSSL is so in use widespread and is critically relied upon even in huge security deployments by governments and security companies!!. Yet, this bug has existed for 2+ years and in the millions of applications no one ever noticed (except NSA, mossad, etc)...

    So I'm gonna run that post for a while, just to stick it to the fanatic assholes.

  53. Re:We protected 1 billion people by notifying trus by Anonymous Coward · · Score: 0

    This was handled similarly to a flaw I discovered, and I think it makes sense. Facebook, for example, has about a billion users. If you have a colleague you trust at Facebook, informing that one colleague can protect Facebook's billion users.

    But I didn't say "Don't tell X", I just don't want X told to the exclusion of Y. Where Y is the vendor a X is a big vulnerable company that you have connections at. If you tell X is an entirely different discussion. OpenSSL should have been near, if not at the top of, the list of groups contacted.

    Also, quit bragging on protecting a billion people. It looks fancy because you're parading around a big number but you didn't protect a single one of those users when they used a vulnerable service that wasn't called facebook.

  54. So funny by Anonymous Coward · · Score: 0

    My personal view is that "responsible disclosure" is just term cooked up by lazy manufacturers.. Where was their own quality assurance and code reviews? They didint bother to do any of that in order to save few bucks more...

    Its like they want headsup so they can sit on it few months, charge customers extra for fix before its public knowledge..

    My personal view is, if you find bug, go public. That way fixes are done faster and as many players in field as bossible gets to know about it...

  55. Re:Actual Experience Against "Responsible Disclosu by raynet · · Score: 1

    Webster was wrong, you never ever should exploit a system you don't own or are hired to pentest. If you find a security hole in a server and they don't respond, you should just go public with the exploit and most likely let someone else to hack the system for you.

    --
    - Raynet --> .
  56. This is the first interesting idea I've read. by Sanians · · Score: 1

    Everyone else is splitting hairs over which permutation of all possible methods is the overall best compromise, neglecting the fact that they all rather suck, but this idea actually has an advantage over the others.

    As for the suggested issue with regard to everyone being too annoyed by having to take services offline for 24 hours, I'm not so sure they'd have to. If you know that the patch won't come out for another 12 hours, then the only people who will know about the bug before 12 hours from now will be any hackers who found it last year and so they've already had plenty of time to exploit you if they'd wanted to. So leaving your server online for the 12 hour period until the patches are released wouldn't be the worst idea. They either exploited you already, or they likely don't care to.

    While some might argue that that's a bad idea since you now know there's an exploit, the truth is that you always knew there were exploits because there are always exploits. The only thing that's changed is that you now know that, in 12 hours, one is about to become much more well-known. So just set your alarm clock and, when the time comes, shut down your server and apply the patch.

    Hopefully some people with mod points will see your comments.

  57. Re:Not that good by viperidaenz · · Score: 1

    I recently worked on a project where two weeks of development time was followed by 4 months of testing.
    Although 3 and a half months of those 4 was waiting for environments to be built and paperwork to go through

  58. Re:Not that good by Anonymous+Brave+Guy · · Score: 1

    Since "people" cannot be negative, by necessity (dev team) + (other people) >= (dev team)

    You're still assuming that the dev teams, or to be more precise the parts of the dev teams who will actively review new code, are the same size. That isn't necessarily true at all, so the "provided everything else is equal" part of your last sentence is the problem here.

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  59. Re:PS: how do you think it gets on the distro mirr by Anonymous+Brave+Guy · · Score: 1

    I think there is a qualitative difference between notifying large end users like Facebook in advance, and notifying people in the distribution system for a general release. It's the former that inherently means the people who aren't large end users with privileged access get left exposed for longer than necessary, and that's what I'm objecting to.

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  60. agreed, openssl should have been notified immediat by raymorris · · Score: 1

    > OpenSSL should have been near, if not at the top of, the list of groups contacted.

    Absolutely. In the case I mentioned where I found the vulnerability, the FIRST contact I made was the development team.

    As to the fact that people can't be protected on every site until the updated packages are out, how does that mean they should NOT be protected when possible? Are you sad that it's "unfair" that they are protected on some sites and not others? So you'd like to remedy that by exposing their data ALL the time? Is that more fair, to have all of their data vulnerable instead?

  61. Re:Not that good by Opportunist · · Score: 1

    So it was 2 weeks of development and 2 weeks of testing. If you can't get laid for a year and then get laid you don't say that you had sex for a year and ten minutes, do you?

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  62. Re:Not that good by jones_supa · · Score: 1

    As he said, they also spent 14 weeks planning and setting up the perfect test environment, waiting for environments to be built and going patiently through all the required paperwork. That sounds pretty responsible to me.

  63. Tom = multiple /. sockpuppet using scum by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  64. Tom = multiple /. sockpuppet using scum by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  65. Tom = multiple /. sockpuppet using scum by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  66. Tom = multiple /. sockpuppet using scum by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  67. Re:Actual Experience Against "Responsible Disclosu by DERoss · · Score: 1

    In the end, the administrator organization for Webster's pension plan was fined by the Australian government for not having proper security for its data, for not properly testing its system, and for not detecting Webster's intrusions (even though the intrusions were very visible in the system logs). Criminal charges against Webster were never pursued.

  68. Let the press know... by Anonymous Coward · · Score: 0

    Heh,keep it quiet so it can be handled in a subtle manner without making any nefarious people more aware that they already were. Then let the press disclose it well before it is fixed, so they can tell other nefarious a$$hats how to leverage it before the door is closed. Yeah, brilliance at its best. Yeah, no good answer is correct.

  69. Re:Not that good by Tom · · Score: 1

    Of course everything else is never equal.

    But what are you trying to accomplish here? Argue that a project with 100 developers has more eyes on the code than one with 4? Moot point, no argument.

    We don't get the luxury of having 50 identical software projects with different team sizes and a size control, so we have to go with the real world and "everything else being equal" is just a way of saying that you if you want to compare closed vs. open source, you need to compare comparable projects, not an open source project with a handful of people with a closed source project two orders of magnitude larger - or the other way around.

    --
    Assorted stuff I do sometimes: Lemuria.org
  70. Re:Not that good by Douglas+Goodall · · Score: 1

    I have to disagree strongly about this. All those rigorous code quality standards and very though code audits haven't done anything to improve the vulnerability situation with Windows. I get the CERT notifications and used to get the Microsoft ones as well, and they all look the same. I vulnerability in the code allows remote code execution and user promotion. The only recommended fix is to turn off some critical feature used by most developers. These bugs always seem to affect all known versions of the operating system, or all known versions of Office. The constant stream of these problems hasn't seemed to slow down at all over the last few decades. It seems to me that there is a major paradigm problem with Microsoft's code concepts, because these problems continue to occur no matter what proprietary development strategy they use. The trusted computing initiative declared all programmers to be untrustworthy and tried to keep them from writing real code. In my opinion all this trouble dates back to the early eighties when Microsoft ignored the boundary protections provided in the protected mode of the 286 and forward. It was just too much trouble for them to manage the descriptor tables and memory regions. Beyond this, Bill Gates opinion that no-one needed more than 640K kept us in tight memory mode too long. Once we got into protected mode and had more memory, it would not have been that much overhead to use the boundary protection. It could have been added to the malloc code and frameworks. Deciding that operating systems should be written in BASIC was another hip Microsoft idea, and Vista proved that one out. Balmer could have been shouting, "marketers, marketers, marketers", and probably was behind closed doors.

  71. Tom = multiple /. sockpuppet using scum by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  72. Tom = multiple /. sockpuppet using scum by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  73. Tom = multiple /. sockpuppet using scum by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  74. Re:Tom = multiple /. sockpuppet using scum by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    (Downmodding the last time I posted this http://slashdot.org/comments.p... Tom? That's all you've GOT vs. your b.s., & using your sockpuppets makes THAT downmod easy to do, now doesn't it ,b>3x in this exchange alone? Just like it would modding YOUR OWN POSTS up!)

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  75. Tom = multiple /. sockpuppet using scum by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    The "BEST TOM HAS" in this exchange? Using his sockpuppets to downmod THIS POST when I posted it before in this exchange:

    http://slashdot.org/comments.p...

    No doubt to effetely & vainly attempt to "hide it"... sockpuppets make downmods of your opponents easy & upmodding your regular Tom account posts up too, doesn't it? You, are lame!

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  76. Tom = multiple /. sockpuppet using scum by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    The "BEST TOM HAS" in this exchange? Using his sockpuppets to downmod THIS POST when I posted it before in this exchange:

    http://slashdot.org/comments.p...

    No doubt to effetely & vainly attempt to "hide it"... sockpuppets make downmods of your opponents easy & upmodding your regular Tom account posts up too, doesn't it? You, are lame!

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  77. Tom downmods using sockpuppets by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    The "BEST TOM HAS" in this exchange? Using his sockpuppets to downmod THIS POST when I posted it before in this exchange:

    http://slashdot.org/comments.p...

    It's only 1 of appromixately 3 or 4 he's done that to here in this exchange since he was "+5 up modded" by his own sockpuppets - go figure!

    Tom downmods there, no doubt to effetely & vainly attempt to "hide it"... sockpuppets make downmods of your opponents easy & upmodding your regular Tom account posts up too, doesn't it? You, are lame!

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  78. Tom downmods using his sockpuppets by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    The "BEST TOM HAS" in this exchange? Using his sockpuppets to downmod THIS POST when I posted it before in this exchange:

    http://slashdot.org/comments.p...

    It's only 1 of appromixately 3 or 4 he's done that to here in this exchange since he was "+5 up modded" by his own sockpuppets - go figure!

    Tom downmods there, no doubt to effetely & vainly attempt to "hide it"... sockpuppets make downmods of your opponents easy & upmodding your regular Tom account posts up too, doesn't it? You, are lame!

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  79. Tom downmods using sockpuppets by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    The "BEST TOM HAS" in this exchange? Using his sockpuppets to downmod THIS POST when I posted it before in this exchange:

    http://slashdot.org/comments.p...

    It's only 1 of appromixately 3 or 4 he's done that to here in this exchange since he was "+5 up modded" by his own sockpuppets - go figure!

    Tom downmods there, no doubt to effetely & vainly attempt to "hide it"... sockpuppets make downmods of your opponents easy & upmodding your regular Tom account posts up too, doesn't it? You, are lame!

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  80. Tom downmods using his sockpuppets by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    The "BEST TOM HAS" in this exchange? Using his sockpuppets to downmod THIS POST when I posted it before in this exchange:

    http://slashdot.org/comments.p...

    It's only 1 of appromixately 3 or 4 he's done that to here in this exchange since he was "+5 up modded" by his own sockpuppets - go figure!

    Tom downmods there, no doubt to effetely & vainly attempt to "hide it"... sockpuppets make downmods of your opponents easy & upmodding your regular Tom account posts up too, doesn't it? You, are lame!

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  81. Tom downmods using his sockpuppets by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    The "BEST TOM HAS" in this exchange? Using his sockpuppets to downmod THIS POST when I posted it before in this exchange:

    http://slashdot.org/comments.p...

    It's only 1 of appromixately 3 or 4 he's done that to here in this exchange since he was "+5 up modded" by his own sockpuppets - go figure!

    Tom downmods there, no doubt to effetely & vainly attempt to "hide it"... sockpuppets make downmods of your opponents easy & upmodding your regular Tom account posts up too, doesn't it? You, are lame!

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  82. Tom downmods using sockpuppets by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    The "BEST TOM HAS" in this exchange? Using his sockpuppets to downmod THIS POST when I posted it before in this exchange:

    http://slashdot.org/comments.p...

    It's only 1 of appromixately 3 or 4 he's done that to here in this exchange since he was "+5 up modded" by his own sockpuppets - go figure!

    Tom downmods there, no doubt to effetely & vainly attempt to "hide it"... sockpuppets make downmods of your opponents easy & upmodding your regular Tom account posts up too, doesn't it? You, are lame!

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  83. Tom = multiple /. sockpuppet using scum by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  84. Tom = multiple /. sockpuppet using scum by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk

  85. Tom downmods using sockpuppets by Anonymous Coward · · Score: 0

    Let's let TOM speak shall we:

    "I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage

    FROM -> http://slashdot.org/comments.p...

    The "BEST TOM HAS" in this exchange? Using his sockpuppets to downmod THIS POST when I posted it before in this exchange (it's only 1 of 4-5 he's done this to USING sockpuppets to upmod himself, & downmod my posts exposing him):

    http://slashdot.org/comments.p...

    (Tom downmods there, no doubt to effetely & vainly attempt to "hide it"... sockpuppets make downmods of your opponents easy & upmodding your regular Tom account posts up too, doesn't it? You, are lame!)

    APK

    P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

    Tom ended up "eating his words" here http://slashdot.org/comments.p... spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

    ... apk