mailing list archives
Re: MSIE (mshtml.dll) OBJECT tag vulnerability
From: Matthew Murphy <mattmurphy () kc rr com>
Date: Mon, 01 May 2006 16:58:41 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Tim Bilbro 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
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
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
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
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
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.
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
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)
-----END PGP SIGNATURE-----
Description: S/MIME Cryptographic Signature
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/