Re: Towards a responsible vulnerability process

From: Kirk Corey (kirk.corey@NEXIQ.COM)
Date: 11/04/01 

Message-ID:  <000001c16554$7bc6f820$0c00a8c0@dsiinc.net>
Date:         Sun, 4 Nov 2001 11:16:45 -0600
From: Kirk Corey <kirk.corey@NEXIQ.COM>
Subject:      Re: Towards a responsible vulnerability process
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

In his article, Scott Culp makes the following statement: "Providing a
recipe for exploiting a vulnerability doesn't aid administrators in
protecting their networks." This statement, and some of the conclusions
based upon it, are incorrect.

When a vulnerability is announced, a system administrator may ask the
following questions:

1. Is my system vulnerable? (If it ain't broke....)
2. If so, should I attempt a workaround?
3. If so, and I configure a workaround, has the workaround now indeed
protected my system against the vulnerability? Or did I make a mistake
somewhere, or misunderstand some part of the advisory, or (fill in the
blank)?
4. Or should I apply the patch?
5. If so, and I do, has the application of the patch protected the system
against the vulnerability? Or is there perhaps something unique to my
configuration that causes the application of the patch to fail without
warning, or to succeed in application, but still fail to protect me against
the vulnerability? (Perhaps I need the workaround after all.)

Questions 1, 3, and 5 will often be answered to a large extent by the
vendor's and/or researcher's initial announcement. However, they can only
be answered definitively and conclusively by actually launching the
exploit, in all known variants, against the system in question.* If I am
unable to do this, because the exploit is not released, I may be deprived
of a tool that I need in order to assure the protection of my system.

QED.

If what's wanted is to improve the current situation, by all means, let's
try-- but let's start with correct and accurate premises.

My $.02,

Kirk Corey
Director, Information Technology
NEXIQ Technologies, Inc.
kirk.corey@nexiq.com
http://www.nexiq.com/

* Yes, this is sometimes a risky manner of testing, but that judgment
belongs to the sysadmin, not the vendor, and not the security community as
a whole, and the risk varies not only according to the exploit itself, but
also to the role of the system under attack (e.g., low risk for
non-production systems).

Relevant Pages

  • Re: Towards a responsible vulnerability process
    ... Towards a responsible vulnerability process ... > protecting their networks." ... Does it have the patch? ... You don't need a script kiddie exploit to know about work-arounds. ...
    (NT-Bugtraq)
  • Re: Data Execution Prevention
    ... > So not only do you complain incessantly about the vulnerability of ... > Microsoft products to intrusions you also deliberately choose to ... > disable one of the ways of protecting against these. ...
    (microsoft.public.windowsxp.general)
  • MS released a patch today - MS06-001
    ... Microsoft released a patch for the WMF vulnerability this afternoon. ... Microsoft has tested the following workaround. ... * Unregister the Windows Picture and Fax Viewer on Windows XP ...
    (Bugtraq)
  • Re: [Full-disclosure] EEYE: Temporary workaround for IE createTextRange vulnerab
    ... On 3/27/06, Marc Maiffret wrote: ... This workaround has been created because currently there is no solution ... you experienced and we will work to fix any bugs in a timely fashion. ... For more information on the vulnerability and a link to download the ...
    (Full-Disclosure)
  • Re: Installing 835732 causes my server to crash
    ... > The FAQ section of the technical bulletin: ... > has workaround information for many of the vulnerabilities in this patch. ... It looks like the LSASS Vulnerability - CAN-2003-0533 ... -- torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway Administration scripting examples and an ONLINE version of the 1328 page Scripting Guide: ...
    (microsoft.public.security)