Re: Internet Explorer 0day exploit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Zow Terry Brugger wrote:
>> What exactly constitutes a 0day? From my perspective naming a
>> vulnerability 0day have absolutely no value whatsoever, it just doesn't
>> make any sense. 0day for who? The person who release it, sure, but for
>> the security community as a whole... nah.
>
> I consider a "0day" to be a vulnerability for which there is an exploit in
> the wild before there's a vendor patch for the problem. If this convention is
> followed, it has value to the community, because we know that having that
> software on our systems presents a significant risk.
Fair point, had not considered that before. It would be better to just
call it active vulnerability vs inactive vulnerability. Active would
define something that yet cannot be prevented and has "wild" exploit
code where a passive vulnerability is something that has been patched
and _should_ no longer be applicable. Anyways, you make a good point.
>
>> I'm also personally starting to question the whole idea behind public
>> disclosure and advisories. Do they actually mean anything these days?
>> What good is it to know about a vulnerability that was "discovered" 6
>> months ago? The important thing is to know what can be done BEFORE the
>> patch has been released.
>
> I presume you're talking about the situations where the researcher has
> coordinated their advisory release with the vendor such that vulnerability
> details are not disclosed before a patch is available. Yes, I still think
> these advisories are valuable because they often provide more details about
> what was broken than the vendor advisories do (which often read, "There's a
> security problem in product X. Install this patch."). Such details allow us
> to learn what goes wrong when building software systems and allows us to
> avoid such problems in the future. Occasionally the advisories from the
> researchers also provide some insight into how they found the vulnerabilities
> (although I've seen this decreasing in recent years), which helps others
> learn how to find vulnerabilities.
Another fair point. It is however rare that enough information is
provided through the advisory to actually "teach" anything about the
particular vulnerability. What you are saying makes perfect sense, in an
ideal world. Many of the advisories I look at almost always cover the
same type of vulnerability. Shouldn't we have learned by now, if we
consider your argument?
However, perhaps one/I just need to shift the way I look at advisories.
Rather than seeing them as "late" and "out-of-date", they could be an
additional source of information about a particular system. I'll accept
that.
>
>> Also a big portion of "advisories" seem to be related to the most
>> obscure softwares and home made PHP applications that most of us never
>> even care about anyway. These advisories clutter the ones that have even
>> the slightest validity.
>
> To some extent, I agree. At the same time though, I think these tend to come
> from people who are learning how to do vulnerability analysis, starting with
> the low hanging fruit. To that end, I think the ability for these people to
> get peer-reviewed feedback on their work is immensely useful to the community
> as a whole.
Yeah, I do agree about that. I don't see much of that feedback, but
perhaps people respond to these researchers privately. A common problem
I see among advisories is that many contain very little information or
are almost at the verge of being completely void. A remedy for that
would be to have the security community agree on a common "advisory
protocol" that defines a guideline for contents in an advisory. Anyways,
moving on.
>
>> One more thing about "advisories". I think it would be better to release
>> them immediately and let people know what they are facing. With public
>> dissemination of a vulnerability perhaps someone will release a 3rd
>> party patch or another inventive way of protecting oneself. Holding it
>> "secret" really doesn't help anyone. If anything it prevents people from
>> trying to find a way to fix the vulnerability.
>
> First off, I don't think anyone can seriously say it doesn't help _anybody_
> -- it certainly helps the vendor. If it's an IDS/IPS company that holds the
> research and they've got a signature out for it on their system, it certainly
> helps them. Here we find a variation on the ancient (in Internet terms)
> argument about full disclosure: if bugs are public knowledge, will vendors be
> more responsive to fixing them? I don't think you're going to see publicly
> developed patches for any but the most extreme cases. At the same time, I see
> some advisories where the vendor was notified more than six months ago and
> just has a patch out now. That's a pretty large window of vulnerability if
> anyone malicious knows about the problem (and if we're finding them in the
> open community, there's no reason they wouldn't). I think security
> researchers need to continue to think about exuding due pressure on vendors
> to get bugs patched.
Yes it sure helps the vendor, but it certainly doesn't help the end
user/customer and in my opinion it is he who matters. The vendor has a
responsibility towards the consumer, not the other way around. By not
exerting any pressure on vendors, I believe things will never change. It
certainly doesn't make any sense for a vendor to become proactive in
making their software more secure. At least not until enough people
start demanding more secure software...
We can speculate back and forth about the impact of "real" public
disclosure without getting anywhere. What we can do however is look at
the past and what works there. Take education for example. Would you
argue that it's better with an educated elite? An elite that holds all
the knowledge and decides when it's time to let the "rest" of us know
something. I for one believe that knowledge should be shared, regardless
of what it's content. People should have the right to decide for them
selves what is better for them and not.
Hmm.. I better stop there as I feel an incoming surge of ranting and
very probable off-topic babble.
>
> My two-bits,
> Terry
>
> #include <stddisclaimer.h>
>
- --
Chris Stromblad (CEH)
Security Engineer
Outpost24 UK
90 Long Acre
Covent Garden
London, WC2 E9RZ
- -------------------------
Tel: +44 (0) 207 849 3097
Dir: +44 (0) 208 099 6595
Fax: +44 (0) 207 849 3140
- -------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGnnQb+CG0a/ZJxn8RAqt7AJ9Oz0NjQyfe3OP46aIh+KjpWV3PEQCgkSHd
z5o7HYmW+uu4ZMNwsNMUIi0=
=MH3x
-----END PGP SIGNATURE-----