On disclosure


Disclosure and responsible disclosure is a very much discussed topics these days as the MOAB (no, not that one – yes it is a cheap shot, but maybe there are people who didn’t read it on ten other blogs :)). Here is one blog entry which says:

I completely disagree with the decision for security companies, researchers and individuals to make information on vulnerabilties, or how to exploit them, public without following responsible disclosure – this is not very responsible Organizations should NOT do business with entities that put our networks at risk – period!

Needless to say I disagree with him completely, one of the reasons being that is business suit type of person (a former Gartner analyst). That said, over on the securosis.com blog you can read a very detailed and very balanced description of the disclosure process and the problems with it.

If you still prefer to read this blog posts, here are the key points you should keep in mind when discussing vulnerabilities:

  • The bugs are not created by the researchers. The bugs are created by the company (or rather the programmers of the company) so morally speaking they are responsible for it (unfortunately with most modern EULAs they have no legal responsibility)
  • The fact that a bug is not widely known doesn’t mean that it’s not known at all. It is very possible that a limited set of people have knowledge of it and are using it for nefarious purposes.
  • Given this fact, any disclosure whether its coordinated with the vendor or not, is a good thing / public service. Even more so when you consider that these very, very smart people do the work for free which the given company failed to do, even with the (hopefully) massive amount of money put in the QA department.
  • One blog post pondered the fact that many people are in the fame business when publishing vulnerabilities, however you have keep in mind that: (a) as one commenter noted: even if they only supply a reliable way to reproduce the bug, this is enough for the programmers to fix it and (b) either there is a sudden increase in smart people (or at least who know how an XSS vulnerability works) or the quality of the programs if very, very low. Either way, remember: they are doing the QA departments job for free! (This is not to say that you should fire your QA department, but at least thing about bringing some of these people on your team)
  • Finally, I have to wonder: would the verdict of the poster have been so harsh if the subject of the talk were business people (as opposed to technological people)?

In conclusion: this is a technological problem first and a PR problem second and should be treated by the companies that way. (Or better said: it is an economic problem first, so treat it like such: offer rewards for vulnerabilities and fix them as fast as possible – think of it as the cost you pay for not following strict security guidelines and rigorous QA testing)

, , , ,

2 responses to “On disclosure”

  1. I’m inclined to agree with you. And in this particular case – MoAB – I find the spectacle of people huffing and puffing about the disclosures rather ridiculous. This has a lot more to do with the “fanboy” phenomenon than with anything else. That’s to say some people have become too invested in a certain image of themselves as Apple-users and don’t like having their tails tweaked.

    Tweaking these people’s tails is, of course, part of the purpose of the exercise (although MoAB has other, and more serious, purposes, too). Hence the logo MoAB uses which is a skit on the “My little Pony” products:

    http://en.wikipedia.org/wiki/My_Little_Pony

    But I do think there is a reasonable objection to the view you express there. That’s that while there may be a very few others who have already found these vulnerabilities and are exploiting them, disclosing them publicly means that there are many more people who now know of them and could potentially exploit them. There must be a larger pool of people who aren’t smart enough to find flaws themselves, but who know enough to be able to take advantage of them once they know of them. Considering that, a private disclosure to the vendor might be thought to be better.

    I’m not sure that’s a telling argument in the end. For one thing, so long as a researcher is prepared to stay quiet the vendor can get away with dragging its feet. In this case, it could be objected that LMH and Kevin Finisterre gave the vendor no time at all to get its house in order. However, they cite previous Apple tardiness, and also express a desire to shake things up a little – so that OS X users become a little less complacent; so I suppose they have an answer to that.

    Anyway, to return to the earlier point, you say: “any disclosure whether its coordinated with the vendor or not, is a good thing”. I suppose that’s right, but formulated like that it doesn’t acknowledge that an “uncoordinated” disclosure may – temporarily – render users _less_ safe.

    I don’t feel at all angry with LMH and Kevin Finisterre, although I use OS X quite a lot. And maybe what they’re doing will have several beneficial effects. But I do think there’s a legitimate – not possibly a conclusive but certainly a legitimate – argument to be made against what they’re doing.

  2. Very good points. Probably there is no definitive answer to this question. Everyone does as s/he sees fits and probably half of the people will disagree with him / her. Still it would be nice from the vendors to (a) fix the flaws as fast as possible and (b) don’t try to wage a PR war against these people (IMHO, this campaign is partially the result of the marketing / PR choices Apple made)

Leave a Reply

Your email address will not be published. Required fields are marked *