OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archive: Vulnerability Escrow (was: Extreme Hacking)

Vulnerability Escrow (was: Extreme Hacking)

Crispin Cowan (crispincse.ogi.edu)
Wed, 07 Jul 1999 00:06:13 -0700

"Craig H. Rowland" wrote:

> > I don't buy that, either. Buffer overflows are gross negligance, and people
> > announcing vulnerabilities (with or without exploits) are just doing a public
>
> I don't consider them gross negligence because they are too easy to do
> with C and C++ which are the accepted "standard" in software development
> today. ... Perhaps
> negligence should fall upon compiler/OS developers too for allowing
> overflows to work and not deployong StackGuard like techniques? The reason
> I don't think buffer overflows are *gross* negligence is that there are
> simply too many people to assign blame to.

Ok. I called it "gross" negligance because it is such an easy problem to fix.
StackGuard is not the first tool to address this problem, just the easiest :-)
Back in 1992 there was Purify. You can grep for strcpy and friends. You can use
a library/linker that bitches when you link to unsafe functions.

You take the position that it's not gross negligance simply because it's very
common. Ok, I guess, but I suspect we're just begging the definition of "gross."
And hence the rampant debate about whether software engineering is actually an
engineering discipline. We all wish it was, but does that make it so?

> > service. If tort law misguidedly starts assigning liability to the practice
> > of announcing vulnerabilities, then it will just go underground and be
> > announced anonymously. If that practice is broken, then vulnerabilities will
> > go even deeper underground and only the bad guys will know about it.
>
> I don't disagree with you on this. I think as a *security company* you
> have a higher standard to live up to than someone outside of the industry.
> My personal take on the issue is two-fold:
>
> 1) I don't mind individuals divulging fully detailed exploits if they feel
> so inclined (although I think there are other ways to handle the problem).
> 2) I do mind security companies doing this.

An interesting distinction. Both individuals and security companies rush to early
disclosure for essentially the same reason: the fame/marketing advantage of being
first. Clearly there is an incentive for both groups to violate the "notify
author before release" protocol.

This problem has lead me to think about a solution to this problem that preserves
the discoverer's "First!" ego/marketing bonus, and yet preserves the protocol,
giving the vendor/author a fair opportunity to provide a fix along with the
announcement. I call it the "Vulnerability Escrow."

Imagine we could create an organization that was trusted by both product vendors
and "l33t do0dz" alike. The Vulnerability Escrow receives vulnerability notices
(with or without an exploit) from the discoverer, returning either "Yes that's
new" or "Sorry, you're not first" to the discoverer. Vulnerability Escrow then
forwards the information to the vendor, and starts a count-down. If the vendor
gets back to VE with a patch or work-around within the time-out period, then the
vulnerability and the patch are simultaneously announced by VE, giving full credit
to the discoverer. If the time-out expires, then just the vulnerability is
announced, again with full bragging rights to the discoverer.

VE is of benefit to the vendors, and offers little advantage to the l33t do0dz, so
how do we interest them? This thing ain't free, so how do we fund it? Answer:
participating companies pony up cash (either per company or per product?) and some
of the cash is turned into bounty for the first discoverer.

Wither CERT? VE could also be viewed as a small policy change from current CERT
activity with a large impact, to wit the time-out. CERT currently sits on
vulnerabilities until either a patch/workaround is available, or an exploit is in
wide usage. Naturally, this does not please the community of discoverers, leading
to the marginalization of CERT.

So, we can either lobby CERT to change policy, or we can try to found a new
organization.

> Also tort law does *many* things that people don't like (in America at
> least). While it may be nice to think that such a suit won't ever happen,
> the reality is it probably will. This issue has transcended the mere
> "information must be free" argument and has landed squarely in the realm
> of good ol' corporate CYA.
>
> Yeah it stinks. Perhaps we should file a class action suit against the
> American Bar Association for the mental anquish they have caused over the
> years.

Works for me :-)

Seriously, the threat of lawsuits has the effect of prohibiting legitimate
security companies from announcing anything, while doing nothing to prevent
anonymous l33t do0dz from announcing in any fashion they please. This does not
encourage responsible vulnerability announcements. VE encourages both the
security industry and the underground to announce responsibly.

> I disagree with this. There are other issues:
>
> 1) They released fully working code before a patch was available.

Fully working exploits are often necessary to be credible. Companies have been
known to stonewall with "that's not a bug, it's a feature" or "yeah, it's flakey,
but it's not exploitable." An exploit ends the waffling.

Either eEye did not believe MS was taking them seriously, or they did this for
publicity. I don't know.

> 2) They released fully working *variants* of the exploit after it was
> established the hole existed.

Likewise.

> 3) The code included methods for immediate remote access which would have
> been just as easily served by other non-intrusive methods for this
> *particular* attack (sometimes this isn't an option though).

I don't veiw this as significant. With a fully working exploit that demonstrates
a harmless "Gotcha!", the underground can have a malicious payload working in
moments.

> Does this mean nobody else would have taken their information and done the
> same? No. Does it illustrate the fact that as a *security company* they
> were a little too eager and should have shown more restraint? Yes.

Possibly, but not necessarily. These actions are also consistent with a response
to perceived stonewalling by the product vendor. I won't make strong assertions
of the particulars in this case, but both responsible and irresponsible motives
exist for these actions.

> > There is a well-established protocol here:
> >
> > 1. Discoverer notifies the vulnerable product's author/vendor.
> > 2. Give them about a week to provide a satisfying response.
> > 3. If no response is forth-coming, then announce the sploit to force some
> > action.
> >
>
> There needs to be consideration of several other factors in your
> protocol as well (especially with respect to point two):

It's not my protocol. I learned it from reading Bugtraq.

> - What is the likelihood the exploit is being actively abused?
> - Unknown exploits should grant the publisher more time to fix the
> problem (of course how do you determine what is and is not
> unknown?).
> - What is a reasonable time estimate for full product patching, testing,
> and deployment by the vendor in question?

And these are considerations that VE can take into account. Escrow is necessary
because vendors have an obivous conflict of interest, and can and have stalled for
months or *years* before releasing a fix, often at the point of a publicly
distributed exploit. VE balances these trust issues between vendors and
discoverers.

Crispin
-----
 Crispin Cowan, Research Assistant Professor of Computer Science, OGI
    NEW: Protect Your Linux Host with StackGuard'd Programs :FREE
       http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/

This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:19:02 CDT