the underground software vulnerability marketplace and its hazards (fwd)

[Ben Laurie]

Marc Branchaud wrote:
> Ben Laurie wrote:
> 
>>Incidentally I was put under a lot of pressure when releasing the
>>OpenSSL advisory a few weeks ago to allow CERT to notify "vendors"
>>before going on general release. I have a big problem with this - who
>>decides who are "vendors", and how? And why should I abide by their
>>decision? Why should I pick CERT and not some other route to release the
>>information?
> 
> 
> I agree that such pressure is pretty reprehensible.  As others in this
> thread have said, it's your decision how you want to publish the
> information.  People should respect that decision.
> 
> However...
> 
> 
>>Also, if the "vendors" were playing the free software game properly,
>>they wouldn't _need_ advance notification - their customers would have
>>source, and could apply the patches, just like real humans.
> 
> 
> I agree with that to a certain extent.  However, we (RSA) recently had
> to release patches to several versions of Xcert's old Sentry CA because
> of the OpenSSL fixes.  I do not know how our customers would have been
> helped by having the source.
> 
> First, I want to point out that Xcert's use of OpenSSL was entirely in
> agreement with OpenSSL's license.  The fact that we built closed-source
> product atop OpenSSL was playing the game properly, as far as the rules
> were laid out.  (If you think OpenSSL's users should behave differently,
> change the license!)

I have two points to make about this:

a) We can't change the licence (until we rewrite the whole thing).

b) I like BSD-style licences because it means people get to use the 
software even if they are doing the wrong thing - but I do hope they'll 
see the light in the end and do the right thing.

> Even if we gave our customers our source code, we had made a few changes
> to the OpenSSL code for use in Sentry CA.  Mostly to deal with things
> like PKCS#11 and ECC (we used OpenSSL for crypto, some ASN.1 and SSL).

Correct answer: contribute the patches back to OpenSSL, then you don't 
have this problem.

> So patches don't necessarily apply perfectly cleanly (though these ones
> did).  It seems unreasonable for us to expect our customers to make the
> appropriate changes themselves.  (We even had to make our own patch for
> a particularly early version of Sentry CA that used a verison of OpenSSL
> that did not get a patch from openssl.org.  There's nothing like money
> to bring out the whore in all of us...)

That's probably fuller of holes than I care to think about.


> Also, one of the selling points of Sentry CA was that it's thoroughly
> tested.  We had to make sure that the patches didn't break the product.
>  Again, we can't really expect our customers to do that themselves.

Vulnerable or potentially flakey would be their choice until you've done 
your testing. I know what I would choose.

> Now, I'm a big fan of open-source software, and am very sympathetic to
> its ideas in many ways.  All I'm trying to point out is that the issues
> aren't necessarily so black-and-white.  We certainly could have
> benefitted from advanced notice of the flaws, but I personally think
> that "vendors" shouldn't get first dibs at any patches.  That said, I
> don't really know what we could've done with the news while waiting for
> OpenSSL's patches to come out.

There would have been patches, too, of course.

>  So the way things happened is probably
> the fairest outcome possible.  It was a rough couple of weeks for us,
> though, getting our own fixes together while OpenSSL was sitting pretty.
>  Customers don't seem to like _knowing_ they're vulnerable, for some
> reason...

Because they know that the attackers know, too, of course.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

Available for contract work.

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff