Re: Towards a responsible vulnerability process

From: David LeBlanc (dleblanc@MINDSPRING.COM)
Date: 11/04/01


Message-ID:  <001501c16579$7ce44f30$0100a8c0@davenet.local>
Date:         Sun, 4 Nov 2001 13:36:23 -0800
From: David LeBlanc <dleblanc@MINDSPRING.COM>
Subject:      Re: Towards a responsible vulnerability process
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM


> From: Geo.

> > how we can encourage vendors to make better products, get
> fixes created
> and
> > applied, and do so without encouraging what amounts to
> network terrorism.
> > That's the goal. Let's try and find ways to get there.

> You make some good points David but there is something you
> ignore as well.

I'm not intentionally ignoring anything. I can easily miss things.

> The whole antivirus community is built on the idea of
> providing additional
> software at an additional cost when the real solution should
> have been to
> patch the base products that allow virus and worm propagation.

Unfortunately, one of the things that needs to be patched to control viruses
are the user's brains, and I don't see a good way to do this.

My smartass comment above doesn't mean that we shouldn't try and find ways
to build software that inhibits viruses. If you run Win2k or XP as a plain
user, you'll thwart most viruses. Finding ways to make products and
operating systems that both have the functionality that people want _and_
are resistant to viruses is an interesting and difficult problem.

> The perfect example of this is codered, the antivirus
> community considers it
> a worm that they protect people against but the real solution
> is to patch
> the OS and www server. Without the details of how this worm
> spread, the
> user/admin community would have been more than willing to
> accept that it was
> a virus and therefore the responsibility of the AV community
> to protect us
> at an additional cost instead of Microsoft's responsibility
> to issue free
> patches for their secure product.

I think there's a misunderstanding - I'm not saying at all that the details
of an existing, active worm or exploit shouldn't be made available. I am
saying that providing information that makes the worm or exploit easy to
write in the first place isn't responsible.

> I have no desire to see security become an additional cost
> industry when in
> reality it is the vendors responsibility to provide the
> secure products they
> claim to be supplying.

I fully agree with you here. However, to use viruses as an example, I do
believe in defense in depth. I don't think virus scanners are going away any
time soon, nor should they. They're a valid part of an array of defenses,
which includes asking vendors to create apps and OS's that are less
vulnerable to viruses. It's a difficult problem, though.

> Making the exploit information
> available only to the
> select club of paid security professionals will allow this
> group to charge
> us for what should be being provided free of charge much like
> the AV vendors
> do.

I'd rather let Scott comment on this part.

> The real question we should be asking is how can this
> information be made
> public in full detail and in a timely yet responsible manner,
> not how we can
> prevent people from finding out the details.

That's really what I'm most interested in - and how much information is
needed to actually protect people. I see a lot of things fixed that never
lead to widespread attacks, and the one thing they have in common is the
lack of a user-friendly script kiddie exploit.

David LeBlanc
dleblanc@mindspring.com



Relevant Pages

  • RE: [Info-ingres] Work-around for no return value from Call Syste m?
    ... for the use of the addressee. ... Neither Npower nor any of the other companies in the RWE Npower group from whom this e-mail originates accept any responsibility for losses or damage as a result of any viruses and it is your responsibility to check attachments for viruses. ...
    (comp.databases.ingres)
  • RE: [Info-ingres] Friday is coming ...
    ... for the use of the addressee. ... Neither Npower nor any of the other companies in the RWE Npower group from whom this e-mail originates accept any responsibility for losses or damage as a result of any viruses and it is your responsibility to check attachments for viruses. ...
    (comp.databases.ingres)
  • installing mod_jk connector
    ... worker# make ... *** Error code 1 ... Please note that whilst best efforts are made, neither the company nor the sender accepts any responsibility for viruses and it is your responsibility to scan the email and attachments. ...
    (freebsd-questions)
  • Re: Towards a responsible vulnerability process
    ... > to build software that inhibits viruses. ... But the vendors responsibility in this case is to give network ... administrators the tools and controls to deal with this problem. ... more and more responsible simply because we security types realize how some ...
    (NT-Bugtraq)
  • RE: [Full-Disclosure] RE: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!
    ... Subject: RE: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434! ... Seems to be the most common opinion of those who have no apparent experience with large networks. ... held no responsibility here, ...
    (Full-Disclosure)