Now It’s Over (For Now)

I finally convinced Thomas to answer my questions (see comments here) about vulnerability discovery and disclosure. He does a great job of proving my points by:

1. Admitting that vulnerability discovery is spinning wheels.

2. Deftly trying to change the subject while confusing correlation and causation.

3. Suggesting we are one step ahead of the Russian Mafia, regardless of the latest 0day proofpoints to the contrary.

4. Acting like a concerned parent making decisions for all the enterprise "problem children" of the world.

5. Contradicting himself in number 3 with an even more glaring admission of bugfinding weakness.

6. Helping me counter the monoculture argument that suggests more patches equals less secure. (Thanks, Tom!)

7. Asserting that all security warnings are a lark. (I don’t believe this one, but he’s on the right track).

8. Suggesting that for 7 years people took dumb pills, got compromised, and never noticed while simultaneously proving that it is possible to find vulnerabilities without the whole disclosure process (e.g. Morris worm).

In the interest of fairness, I am now happy to answer any questions about discovery and disclosure that Thomas or other bugfinders have for me about my position.

7 comments for “Now It’s Over (For Now)

  1. September 6, 2006 at 12:40 pm

    Regarding (8), I’m not “suggesting” anything. I said, “Because from 1988 to 1995 there wasn’t a single buffer overflow advisory, despite the fact that the Morris worm exploited one.” That’s fact. Can you to refute?

  2. September 6, 2006 at 12:42 pm

    BTW, you can be as deceptive contrarian as you want; I’m not linking to these posts. You’re not arguing. You’re trolling.

  3. Pete
    September 6, 2006 at 2:39 pm

    @Thomas -

    Regarding (8), I don’t have any evidence to the contrary so I definitely don’t dispute that point. However, maybe I missed your reasoning for using it in response to my question. I assumed you were saying that people were being compromised left and right yet nobody knew about it. If that is a bogus assumption, my mistake. In that case, if you are suggesting that for a 7 year period there weren’t any attacks going on, then I would be a very happy camper with that situation. Are you suggesting that 7 years without attacks is a bad thing or they really happened and nobody noticed?

    Regarding my deceptiveness – I am happy to clarify any point I made above. I agree it is brief, but I am willing to explain myself if it would make things clearer. I am still looking for any evidence other than opinions that vulnerability research is a good idea and the benefits derived could not have come without it.

    Regarding your “not linking” and my trolling of my own site… come again?

    Just to clarify, I didn’t bring up this issue again, Rich Mogull did. I am happy to respond anytime it is brought up just to ensure that the other side of the argument is heard (it is lonely over here, yes indeed).

  4. September 6, 2006 at 2:47 pm

    You’re grossly misrepresenting my comments and making points you don’t even agree with (you’re contradicting yourself) in order to get attention. That’s fine, I do it too, but I’m not going to penalize my readers with it. =)

    As for point (8): we “knew about” buffer overflows for over 7 years, but until individual buffer overflows began to be disclosed, virtually every piece of network software deployed on the Internet was vulnerable. That, also, is not a “suggestion”; it’s a fact, which you can verify in a bug database.

    The fact that there isn’t a continuing stream of buffer overflow in (for example) Sendmail is another fact. It’s a direct result of discovery and disclosure (Sendmail vulnerabilities fixed after 3rd party disclosure outnumber those fixed internally).

    We will never run out of vulnerabilities. But we WILL, for example, run out of stack overflows triggered by insecure usage of sprintf(). You are conflating those two facts in your syllogism about why “bugfinding” is pointless.

  5. Robert E. Lee
    September 7, 2006 at 3:49 am

    Some more opinions on the subject of full-disclosure vs responsible disclosure are available here – http://www.securityfocus.com/columnists/415/1

    @Pete – Do you have the same disdain for so-called responsible disclosure as you do for full and immediate disclosure?

    If I understand your position correctly, you would rather the industry focus on preventative solutions rather than looking for or tracking vulnerabilities at all.

    Robert

  6. Pete
    September 7, 2006 at 10:57 am

    @Robert – I think of bugfinders as arrogant Don Quixotes – they think they are doing the right thing and have decided to force it on us. (That’s one of the strange things about online risk – we’re all connected).

    re: Disclosure – simply a smokescreen and completely out of the control of any individual (who is always the victim of the attack). To the extent people can control it, no disclosure is better. Even better is to not bother looking for another buffer overflow and (to answer your question) come up with techniques to stop all of them, regardless of whether we know about them or not.

  7. Pete
    September 7, 2006 at 11:11 am

    @Thomas -

    - You have the opportunity to try to manipulate your readers however you see fit.

    - Software developers and users (the people whose opinions bugfinders completely ignore) didn’t care about buffer overflows for seven years, and what did it get them? Nothing (in a good way). You’re vulnerable now in lots of ways you don’t know. You’re really going to have to accept it because there is nothing anyone is doing to protect against this REAL vulnerability except distract potential victims. Go to McDonald’s every day – food there is really tasty.

    - I am confident that Sendmail would be “secure enough” to users regardless of what was discovered and disclosed. Since we can’t change the past, we’ll never know. Regardless, for every SendMail out there, there are 10 other applications with vulnerabilities.

    - Glad to see you can protect against one type of attack. If you want to keep track of sprintf() vulns, you go for it. If I can get the same result with another vuln, it doesn’t matter.

Comments are closed.