Re: Towards a responsible vulnerability process

From: Geo. (georger@NLS.NET)
Date: 11/05/01 

Message-ID:  <001501c165a4$bcf5ecc0$0a1a90d8@ntauthority>
Date:         Sun, 4 Nov 2001 21:47:36 -0500
From: "Geo." <georger@NLS.NET>
Subject:      Re: Towards a responsible vulnerability process
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

From: "David LeBlanc" <dleblanc@MINDSPRING.COM>

> 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.

I don't really consider it a smartass comment, it rings with a lot of truth.
But the vendors responsibility in this case is to give network
administrators the tools and controls to deal with this problem. For example
when someone demonstrates repeatedly that they cannot be trusted with the
responsibility for operating a motor vehicle responsibly we take their
license away from them for a period. Users have a responsibility and when
they prove they can't handle that responsibility then administrators need
the controls to remove the capability either for a period of time or
permanently.

A simple switch in MTA's that allows an administrator to immediately block
all attachments upon discovery of a new email based virus would be a welcome
capability as it would allow us to shut the door until the proper AV filters
have been updated. (as just one example)

> 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.

In an application market where feature saturation is becoming a problem I
would think vendors should be thrilled at the idea of a much needed feature
that would differentiate their products from the rest and motivate users to
upgrade.

> 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 think that's a judgement call. Certainly in the case of IIShack I would
agree with you that it wasn't neccessary to go to a full exploit. However in
the case of the ::$DATA asp exploit I think it was totally appropriate
because it allowed the security community to come up with a filter even
before MS had a fix available (that gave us a choice even after MS released
a patch). Also knowing the details of the unicode exploits helped educate
administrators to the value of not accepting the default install paths for
IIS.

> 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.

There are two points I'd like to make in response to this.

1) The full disclosure methods were developing nicely, things were getting
more and more responsible simply because we security types realize how some
of the exploit code was creating problems. The responsible individuals
posting to the lists were allowing more time for vendors to patch and they
were beginning to make judgment calls on how much information was really
necessary for the security community to respond to the threat effectively.
I'd like to see that process develop naturally instead of having this
valuable resource legislated out of existence.

2) There are people who are not white hats who were contributing information
to the security lists in the form of working code exploits (for their own
reasons). Information that would have only been released to the black hats
had it not been for the open nature of the security lists. Surely it is
better for the white hats to get that information at the same time the black
hats get it rather than days or weeks later when it's actively being used?

Geo.

Relevant Pages

  • Re: Pentester convicted..
    ... and thus politely forcing them take responsibility for the protection of privacy of the data they carry. ... and ignored the first 2 reports. ... A security pro notices a flaw, checks to make sure he is not on crack ... Download FREE whitepaper on how a managed service ...
    (Pen-Test)
  • Re: Talk about "Fucking the Troops Around"
    ... a country at peace (where it should be the responsibility of the police ... What are the duties of an occupying force to provide security? ... not possible to compare the salary paid to a contractor to that paid to, ... Just like Walter Reed was a mistake? ...
    (rec.bicycles.racing)
  • Re: Zonealarm
    ... responsibility to cover their transgressions. ... He wasn't the one who was asking for advice. ... You came here ignorant of the business model, ... You came here ignorant of the security model, ...
    (comp.os.linux.security)
  • RE: How hackers cause damage...
    ... "Security Companies" that do not lock down systems or give ... Having enough people to completely secure all ... responsibility for negligence - systems are not always secured. ... be helpful to prosecute the person that *exploited* a vulnerability ...
    (Security-Basics)
  • Re: Is MSIE dead as a browser - if Microsoft does not patch it then it is as far as I am concerned!
    ... it has to do only with ultimate responsibility. ... might not know better when it comes to doing timely security updates, ... Most malware uses some sort of buffer overflow exploit. ... How many patches will it take to make my XP OX as secure as my ...
    (microsoft.public.security.virus)