Date: Mon May  1 22:57:23 2006
From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: MSIE (mshtml.dll) OBJECT tag vulnerability

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Tim Bilbro wrote:
> Bkfsec wrote:
> 
> ...
> 
>> "What you do usually see with full disclosure (likewise with patching),
> 
>> which is ironically dragged out as an argument against full disclosure,
> 
>> is that when a flaw is disclosed, you do see script kiddies coming out 
>> of the woodwork making loud noises with automated bots mass-owning 
>> systems.  Is this the fault of full disclosure?  Nope.  It's 
>> inevitable.  "
> 
> 
> I don't think it is inevitable. 

No offense intended here, but to argue that point is deluded.  If
there's sufficient value to discovering it, it will be discovered.

> Think about browser DoS vulnerabilties.
> An stealth blackhat wouldn't bother with that type of exploit. It's
> brute force, messy, doesn't get you root and it's trackable to some
> degree. But, lesser hackers will immediately adopt exploits that just
> crash the browser for example. So, by publishing that type of exploit
> and labeling it crtical you create a new requirement for mitigation that
> wouldn't otherwise be there. 

This is a TERRIBLE example.  Some vendors (Microsoft) don't patch
browser DoS bugs unless they've later proven exploitable.  Most of the
community doesn't even consider them vulnerabilities.  Further, the
mitigation is so simple that it doesn't even require policy to
implement: if your browser crashes, don't go back to that site.

Put simply: if you discover that doing something hurts, don't do it
again.  There's no continuing damage.  It's a fundamental law of browser
security that nobody can force you to go to a malicious site, and
crashing a browser is not a sufficient inconvenience that policy
mitigation or security assets are required.

Because such methods are trivial to discover (and some are simply
matters of heavy-client design) and difficult to effectively fix,
there's substantial motive and ability within the group we'd normally
consider "script kiddies" to find such bugs.

> Some have suggested a 'Vulnerability Escrow' A third party that tracks
> and holds vulnerability discoveries and works with the vendor. I think
> that is an idea worth exploring. 

It's an idea that's been explored and failed miserably.  As Valdis
already hinted at, CERT/CC is a disaster.  Public disclosure of
vulnerabilities provides the only means of accountability.  Would you
support a "vulnerability escrow" that sat on reports of security holes
for an eternity if a vendor decided patching them was too much of an
inconvenience?

I sincerely hope not, because I know that I would have no part in such
"disclosures".  Further, as a member of the public, I'd object strongly
to their existence.  Surprise: CERT/CC did exactly that when it began.
Unfortunately, when you deny the public information, they have no
calling to hold the vendor accountable.  Incomplete information also
hinders the ability of the public to even make a reasonable guess as to
the security of the product and the commitment of its developer to that
security.

Oracle, for instance, is laughed at because they take 800 or so days to
fix serious security holes and only occasionally get it right.  In your
world of "escrow", nobody knows that, because there's no public
information.  So, people aren't informed and as a result, can't stay
away from vendors whose security processes are colossal failures.

But it gets worse.  What about in an "escrowed" world when vendors do
release patches?  How do admins prioritize?  Or do they just blindly
apply every patch and hope nothing breaks?  Because you can bet that
people will be out there taking apart those patches and finding what
they fix.  Anybody who doesn't apply them in that short (and shrinking)
timeframe is begging to get owned, and wouldn't even have a clue.

Further, how do you propose to make people USE such an escrow system,
especially if it denies them the choice of public disclosure?  How do
you ACTUALLY propose to deny people that choice?

Ooooh, ooh, I have some ideas!

1) Let's all rally around some toothless standard that says "We, the
vendors agree to patch within two centuries" with all accountability
stripped away by non-disclosure.  The vendors are trustworthy, and
they'll all patch, because your security (and not their bottom line) is
the priority.

2) Let's have the U.S. pass another speech-squelching law ala DMCA,
export it to every country with a computer via fifteen thousand FTAs
promising the "enormous benefits" of "free access" to a U.S. economy
where everything from abortion to broad-tipped markers is
puritanically-regulated and make it so that reverse-engineering patches
is...

illegal!!!  That would solve it!

Seriously now... you've gotta be kidding me.

But let's take it another step.  Since we can't actually STOP people
from reversing patches, let's just NOT PATCH!  Trust our luck.  Let's
all just be birds flying through the sky waiting for the first
moderately-clued malicious person with the tools to shoot technical
innovation down.  Let's just give up on informing ourselves and remain
ignorant, because all our problems will just GO AWAY if we ignore them.
 And, better, when we *ARE* attacked, the damage will be orders of
magnitude greater, because NOBODY will be patched.

Great idea!

If you want to see how people are harmed by speech-suppression laws that
merely try to extend the time until we're attacked (rather than prevent
that attack), talk to Kevin Finisterre.  Or David Litchfield.  Or Ed
Felten.  Or Luigi Auriemma.  Or Michael Lynn.  Or any number of other
individuals threatened with lawsuits and life-ruining blackballing at
the hand of a major corporation for simply revealing vulnerabilities.

And if you want to see how *you* as a member of the public are hurt by
those laws... talk to the people who backed down in the face of those
threats.  What's that, you say?  You don't know who they are?  Of course
you don't.  That's the *idea* of such laws.  And don't think it doesn't
happen.  Look at what would've been upon us had ISS had its way with
Mike Lynn.

Then, and only then, can you truly understand the dangers of suppressing
free speech.  Freedom and safety can rarely be traded in any meaningful
fashion.  Freedom and ignorance, on the other hand, can be freely exchanged.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB5444D38

iD8DBQFEVoSRfp4vUrVETTgRA5F1AJ9kCfwe40Vv2TVRBfzOkm7thC40twCeJdc+
rpgSuHIJ8c5z6YnNHy+X1mM=
=YIdA
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3729 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060501/26f0a657/smime.bin

Powered by blists - more mailing lists