RE: Month of Kernel Bugs - day 1

[Gadi Evron <ge () linuxbox org>]

On Fri, 3 Nov 2006, Craig Schmugar wrote:
> > Without that exploit code, only select few can protect themselves, if at
> all.
>
> In principal I agree with you, but in practice (with public exploit code) I
> see few protecting themselves and a bunch exploited.

In theory, I agee with you. In practice, you are no longer correct. What I
see is popular exploitation by mass means that would use whatever is
available, and do so daily, while without the "proof" of an exploit code,
we would see no vendor patches.

> Without the exploit code, I see few exploited.  Yes, it's hard to assess how
> many are affected from an unknown vuln, but I am not aware of a case where
> more were affected before an exploit became known compared to after the
> exploit was made public.

And yet, massive exploitation CAN be averted. Other attacks which
obviously happen, can not. Over-all, when vendors are forced to patch, we
all become more secure.

If some do not patch, it is a different issue all together. Now, I have to
agree that no mater the reason, these people still get compromised. Thing
is, they already are.

> Many are sacrificed for the good of a few.  Better to have the information
> in the hands of the few who can and do protection themselves, than share it
> with the world (idealistic, I know).

Excuse me? Up to this point I was with you. Secrecy has its place, yes,
but the days of numbered few ruling realms of safety and money, where the
oposition of theives and bagabonds is on top of it and attacks
relentlessly are over.

Erm - take a look at how futile hoarding viruses is today, when they are
everywhere. In theory, sharing viruses is pure evil. In today's world, in
practice, it "saves lives".

> Additionally, hackers are being taught concepts to go find many more
> vulnerabilities, and there's no way vendors can patch at the pace that many
> attackers can create exploits.  Attackers are given tools to make the job
> easier, and to circumvent mitigation.

That I can not accept. It is about what's important enough to invest
in. Whether releasing more secure products to begin with, or to patch them
after-wards.

> So the tools are distributed to create a level playing field, right.  If the
> good guys have the tools that the bad guys have, they can anticipate the
> attack.  Vendor's QA teams can find the vulnerabilities before products
> ship.  Consumers of those products can find the vulnerabilities before
> they're attacked.  Security providers can use the tools to create proactive
> protection before attacks happen. However, any 1 vendor, consumer, or
> security provider can not contend with an army of attackers.  And even if
> they could, you're talking about attacking the infinite space.  So you could
> find and fix/mitigate tons of vulnerabilities and they may not be the
> "right" ones.  Which takes me back to the notion of providing the tools to
> the good guys without helping the bad guys.

Bad guys don't need help, and vendors have nulnerabilities being published
equal to their size and MONEY infrastructure.

In other words: excuses.

History has already shown that without the threat of full disclosure,
vendors do not care in any way about fixing vulnerabilities. That is why
bugtraq was created. Today's imperfect world of "some vendors being
proactive or even reactive" is thanks to full disclosure as a threat,
which was proven.

History you say? No longer relevant?

Look at the gaming world going through this stage. Look at SCADA systems
vendors, going through exactly the same problems. They are all about to
start facing the world of full disclosure. Sounds scary? Good.

> "Good guys" is not limited to the vendor themselves.  Vendor pressure was
> one of your earlier points.  Whomever can apply such pressure can be given
> the exploit with the understanding that they may share it with the vendor
> and no one else or they will be cut off the next go around.  Or that they
> only get the exploit if they agree to pressure the vendor, etc, etc.

But the world doesn't work like that. Exploits exist, being sold and
used. While we rely on software which is simply insecure.

> So you ask, what about the small fish, how are they to protect themselves?
> I'll refer to my earlier statement about the good of the many outweighing
> the good of the few, and in most cases I'd argue that those few are at
> reduced risk through obscurity.  Plus, even those with the means to protect
> themselves often struggle to do so (including the small fish).

Okay. I am putting you in the mass that can't protect itself. Now make
that statement again.

You surprise me by having some good arguments on one side, and then a ton
of excuses on the other.

> Craig

        Gadi.

> -----Original Message-----
> From: Gadi Evron [mailto:ge () linuxbox org] 
> Sent: Thursday, November 02, 2006 7:39 PM
> To: Craig Schmugar
> Cc: 'Fergie'; funsec () linuxbox org
> Subject: RE: [funsec] Month of Kernel Bugs - day 1
>
> On Thu, 2 Nov 2006, Craig Schmugar wrote:
> > [Gadi] You know how insecure you are, and what you need to protect
> yourself.
> > What programs to use, what not to use. What IDS signatures you may 
> > need, and what  vendor you need to preasure.
> >
> > [Craig] My point is that the majority of the Internet will not know 
> > (and subsequently not protect themselves, and not pressure the vendor 
> > -- most aren't equipped to do so anyway).
> >
> > [Gadi] Many of these have exploit code in the hands of bad people, so 
> > YES, we will see worms using this as a direct result, but we will also 
> > no longer see  many directed attacks using them.
> >
> > [Craig]
> > Have to disagree there.  WMF, createTxtRange, MS06-040 etc were abused 
> > much
>
> I agree with you Craig, but our problem is one of definitions. of the two
> above - WMF and createTextRange were both 0days, exploited in the wild
> before public disclosure.
>
> > more after exploit code was readily available and Blaster and Sasser 
> > may never have existed if exploit wasn't so public.
> >
> > I am not saying that hackers don't exploit unpublished vuln, of course 
> > they do, but the number of victims and amount of damage jumps 
> > exponentially once that exploit is readily available.  And I can't 
> > endorse irresponsible disclosure.  One of the arguments for 
> > irresponsible disclosure is that certain vendors won't release a patch 
> > or will take too long to release a patch without it.  However, when 
> > you have 0-day threats like CVE-2005-0944 that have remained unpatched 
> > for more than 18 months (Ok, maybe this isn't your average 0-day 
> > response), you have to wonder how strong that argument is anymore [and 
> > I use this example as it's still an actively exploited remote code
> execution vulnerability].
>
> I agree, 100%, that public exploit code is directly responsible for worms
> and bots exploiting new vulnerabilities. It's an industry, without this
> exploit code, they use something else.
>
> Without that exploit code, only select few can protect themselves, if at
> all.
>
> Without that publicity, we would not know we are vulnerable.
> The world is changing, unfortunately.
>
>       Gadi.
>
> > Craig
> >
> >
> > -----Original Message-----
> > From: Gadi Evron [mailto:ge () linuxbox org]
> > Sent: Thursday, November 02, 2006 12:13 AM
> > To: Craig Schmugar
> > Cc: 'Fergie'; funsec () linuxbox org
> > Subject: RE: [funsec] Month of Kernel Bugs - day 1
> >
> > On Wed, 1 Nov 2006, Craig Schmugar wrote:
> > > > As an educated consumer: yes.
> > >
> > > Then I'll add the word "all" to my statement [I might question the 
> > > phrase "these days" in Gadi's statement "you are all more secure 
> > > these days"]
> > >
> > > all <> "educated consumer"
> >
> > Erm, all more secure these days, as a statement, links back to my 
> > previous words in that paragraph/text.
> >
> > Why do you disagree, let's open it for discussion.
> > > Craig
> > >
> > > -----Original Message-----
> > > From: Fergie [mailto:fergdawg () netzero net]
> > > Sent: Wednesday, November 01, 2006 8:02 PM
> > > To: craig () getvirushelp com
> > > Cc: funsec () linuxbox org
> > > Subject: RE: [funsec] Month of Kernel Bugs - day 1
> > >
> > > As an educated consumer: yes.
> > >
> > > - ferg
> > >
> > >
> > >
> > > -- "Craig Schmugar" <craig () getvirushelp com> wrote:
> > >
> > > Patch patch patch?  What patch?  Last time I checked there were 2 or 
> > > maybe 3 patches available for the 25 IE-related MoBB issues (from July).
> > >
> > > So, I might question the phrase "these days" in Gadi's statement 
> > > "you are all more secure these days"
> > >
> > > Craig
> > >
> > > -----Original Message-----
> > > From: funsec-bounces () linuxbox org 
> > > [mailto:funsec-bounces () linuxbox org]
> > > On Behalf Of Valdis.Kletnieks () vt edu
> > > Sent: Wednesday, November 01, 2006 10:02 AM
> > > To: Gadi Evron
> > > Cc: FunSec [List]
> > > Subject: Re: [funsec] Month of Kernel Bugs - day 1
> > >
> > > On Wed, 01 Nov 2006 10:41:17 CST, Gadi Evron said:
> > > > And don't anyone dare speak against HD Moore. He is the reason you 
> > > > are all more secure these days. Not less so.
> > >
> > > Amen to that - fire up Metasploit, build and launch something, and 
> > > then mention that *every* hacker has a copy.  Makes even the most 
> > > recalcitrant user curl up like a breaded prawn and want to go home 
> > > and patch patch patch
> > > ;)
> > >
> > > (That, and Metasploit building blocks are an *incredible* reference 
> > > if you're building *other* tools to look for either exploits or
> payloads.
> > > ;)
> > >
> > >
> > >
> > > --
> > > "Fergie", a.k.a. Paul Ferguson
> > >  Engineering Architecture for the Internet  fergdawg(at)netzero.net 
> > > ferg's tech blog: http://fergdawg.blogspot.com/
> > >
> > > _______________________________________________
> > > Fun and Misc security discussion for OT posts.
> > > https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
> > > Note: funsec is a public and open mailing list.

_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.