RE: Six Step IE Remote Compromise Cache Attack

From: Tyler Larson (noreply_at_tlarson.com)
Date: 11/06/03

  • Next message: Jim Prewett: "DoS for Ganglia"
    Date: Thu,  6 Nov 2003 11:55:19 -0600
    To: white colin john <cjwhite1@ehlnx13.ews.uiuc.edu>
    
    

    Quoting white colin john <cjwhite1@ehlnx13.ews.uiuc.edu>:

    > On Wed, 5 Nov 2003, Thor Larholm wrote:
    >
    > > This post raises an interesting question. Is our goal to find new
    > > vulnerabilities and attack vectors to help secure users and critical
    > > infrastructures, or is our goal to ease exploitation of existing
    > > vulnerabilities?
    >
    > If there's no proof-of-concept that shows current bugs can be combined
    > into an exploit, is there any pressure on microsoft to patch the bugs?
    >
    >

    I'm surprised that nobody has taken issue with this statement. I think
    that in this case Msft would continue to drag its feet for years to come, and
    Liu was justified in posting the exploit. However, I think that in the
    general case (expecially those dealing with entities other than Msft) the
    statement is not always accurate.

    When dealing with projects and organizations with security-minded developers--
    take the OpenSSH project or vsftpd, for example--extremely little coersion is
    necessary. Just email the developer and he'll fix it immediately.

    In fact, I'd go as far as to say that in dealing with any open-source
    software at all, development of a POC exploit is never necessary. It's
    generally easier (and always more productive) to develop the fix than the POC
    anyway. And if a vendor patch exists, POC code won't help anybody. Why?
    Because the existance of a security patch already adequately demonstrates the
    existance of a potential threat.

    People who develop exploit code should think REAL HARD about why they're
    doing it before they start. If you're writing it simply because nobody else
    has yet, you should definately reconsider: there's probably reasons why no
    one has written it before--do you really think you're the first one to know
    how? If you're trying to impress you're peers (i.e. get a job) think again.
    Attention you get by acting irresponsibly is not the attention you want. If
    attention is a motive, it should be a secondary motive rather than a driving
    one--otherwise it gets in the way of common sense. Attract attention while
    doing the "right thing" (i.e. developing POC exploits only when they're
    needed). It produces better results anyway.

    As stated before by others, proof-of-concept exploit code serves one major
    purpose: It lights a fire under a slow-moving organization to quickly develop
    a fix. It's important to understand how, though. It does it by:

    * Convincing the company that the threat is real. We like to think this is
    all we're doing, but it's only a very small part of the process.

    * Increasing the threat by aiding in the development of worms and viruses.
    Sad but true, this is a major reason why exploit code speeds things up.

    * Turning public opinion against the company. They clean it up only because
    it would be a PR nightmare if they didn't.

    Exploits, even POC exploits, do a LOT of damage, whether you like to belive
    it or not. That's the whole reason why they work--they absolutely force the
    company to fix the problem in order to stop the bleeding. That's why
    Microsoft HATES the whole concept of full disclosure (a few choice Ballmer
    quotes may come to mind). There's really nothing innocent or harmless about
    it.

    In certain situations, though, the general pubic (though probably not the
    company) is better off because the exploits forces the company to fix its
    mistakes. In those select few situations, I say the developer is justified in
    writing the exploit. The rest of the time, though, I say he's just being a
    public menace.


  • Next message: Jim Prewett: "DoS for Ganglia"

    Relevant Pages

    • Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
      ... I've yet to see a developer commit on the list that they WILL fix it ... hot plug support) IS NOT IN THE FIX PROPOUNDED UPON! ... the money would BUY. ... sharing a network connection with production machines is entirely isolated - ...
      (freebsd-stable)
    • Re: periodic frustration
      ... This is exactly the point of autotools: ... It is not there to make your life easier as a developer. ... fix it ... ... Program needs version x.y of autothis, ...
      (comp.unix.programmer)
    • Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
      ... developer to fix it. ... usage on the SDK and AppStore acceptance process and you get developers ... to fix their apps before they reach the device. ...
      (Linux-Kernel)
    • Re: Documentation: term for new issues discovered
      ... fix another issue? ... We call everything 'defects' regardless of what they are. ... It is perfectly legal for a developer to notice ... test differently than validation does. ...
      (comp.programming)
    • Re: Critical bug in GnuTLS
      ... Do they fix the bug? ... The article pointed to by poc states.... ... Getting tired of non-Fedora discussions and self-serving posts ...
      (Fedora)