RE: Six Step IE Remote Compromise Cache Attack
Quoting white colin john <cjwhite1@xxxxxxxxxxxxxxxxxxxx>:
> 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.