We have had fine results with just checking for the running of Windows
Update. Also, like most, CCA is only a part of the overall method for
securing our RESnet.
Greg
Simon Kissler wrote:
> I have to say that after some of our pre-CCA experiences with Viruses and
> such and the number of calls we'll get when people have the vulnerability
> I'd rather spend the time to do manual installs and or use something like
> bitsfix than risk our students not having the patches installed and us
> having to deal with the aftermath.
>
> -S
>
>
>
> On Fri, 25 Aug 2006, Rajesh Nair (rajnair) wrote:
>
>
>> Return-Path: <[log in to unmask]>
>> Received: from localhost by genesis with LMTP; Fri,
>> 25 Aug 2006 13:40:11 -0500
>> Received: from smtp03.valpo.edu (smtp03.valpo.edu [152.228.33.53])
>> by genesis.valpo.edu (Switch-3.1.7/Switch-3.1.0) with ESMTP id
>> k7PIeBbf002821;
>> Fri, 25 Aug 2006 13:40:11 -0500 (CDT)
>> Received: from localhost (localhost [127.0.0.1])
>> by smtp03.valpo.edu (8.13.7/8.12.9) with ESMTP id k7PIe7WB019916;
>> Fri, 25 Aug 2006 13:40:07 -0500 (CDT)
>> X-Virus-Scanned: by amavisd-new at valpo.edu
>> Received: from smtp03.valpo.edu ([127.0.0.1])
>> by localhost (smtp03.valpo.edu [127.0.0.1]) (amavisd-new, port 10024)
>> with ESMTP id L8iaBGge0SD4; Fri, 25 Aug 2006 13:40:05 -0500 (CDT)
>> Received: from listserv.muohio.edu (listserv.muohio.edu [134.53.7.26])
>> by smtp03.valpo.edu (8.13.7/8.12.9) with ESMTP id k7PIe56o019898;
>> Fri, 25 Aug 2006 13:40:05 -0500 (CDT)
>> Received: from nasw2k01 (listserv.muohio.edu) by listserv.muohio.edu
>> (LSMTP for Windows NT v1.1b) with SMTP id
>> <[log in to unmask]>; Fri, 25 Aug 2006 14:40:04 -0400
>> Received: by LISTSERV.MUOHIO.EDU (LISTSERV-TCP/IP release 14.5) with
>> spool id
>> 50811395 for [log in to unmask]; Fri, 25 Aug 2006 14:38:45
>> -0400
>> Received: from mulnx11.mcs.muohio.edu by listserv.muohio.edu (LSMTP for
>> Windows
>> NT v1.1b) with SMTP id <[log in to unmask]>; Fri,
>> 25 Aug
>> 2006 14:38:44 -0400
>> Received: from mulnx23.mcs.muohio.edu (mulnx23.mcs.muohio.edu
>> [134.53.6.10]) by
>> mulnx11.mcs.muohio.edu (Switch-3.1.8/Switch-3.1.7) with ESMTP id
>> k7PIchkE004152 for <[log in to unmask]>; Fri, 25 Aug 2006
>> 14:38:43 -0400
>> Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com
>> [171.71.176.117]) by
>> mulnx23.mcs.muohio.edu (Switch-3.1.8/Switch-3.1.7) with SMTP id
>> k7PIcgeD007475 for <[log in to unmask]>; Fri, 25 Aug 2006
>> 14:38:42 -0400
>> Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by
>> sj-iport-6.cisco.com
>> with ESMTP; 25 Aug 2006 11:38:42 -0700
>> Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
>> by
>> sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
>> k7PIcgjZ003509 for <[log in to unmask]>; Fri, 25 Aug 2006
>> 11:38:42 -0700
>> Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
>> [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with
>> ESMTP
>> id k7PIcfYp010099 for <[log in to unmask]>; Fri,
>> 25 Aug 2006
>> 11:38:42 -0700 (PDT)
>> Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by
>> xbh-sjc-211.amer.cisco.com with Microsoft
>> SMTPSVC(6.0.3790.1830);
>> Fri, 25 Aug 2006 11:38:41 -0700
>> X-MimeOLE: Produced By Microsoft Exchange V6.5
>> Content-class: urn:content-classes:message
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset="us-ascii"
>> Content-Transfer-Encoding: quoted-printable
>> X-MS-Has-Attach:
>> X-MS-TNEF-Correlator:
>> Thread-Topic: Microsoft Windows Update Website
>> Thread-Index: AcbHgUbL2KaVvGHfSEGrE5jGPqPGMQA1PETgAAd183A=
>> X-OriginalArrivalTime: 25 Aug 2006 18:38:41.0861 (UTC)
>> FILETIME=[B0256F50:01C6C875]
>> X-Real-ConnectIP: 171.71.176.117
>> X-Scanned-By: MIMEDefang 2.57 on 134.53.6.66
>> X-Scanned-By: MIMEDefang 2.52 on 134.53.6.10
>> Message-ID:
>> <[log in to unmask]>
>> Date: Fri, 25 Aug 2006 11:38:41 -0700
>> Reply-To: Perfigo SecureSmart and CleanMachines Discussion List
>> <[log in to unmask]>
>> Sender: Perfigo SecureSmart and CleanMachines Discussion List
>> <[log in to unmask]>
>> From: "Rajesh Nair (rajnair)" <[log in to unmask]>
>> Subject: Re: Microsoft Windows Update Website
>> To: [log in to unmask]
>> Precedence: list
>> List-Help: <http://listserv.muohio.edu/scripts/wa.exe?LIST=PERFIGO>,
>> <mailto:[log in to unmask] PERFIGO>
>> List-Unsubscribe: <mailto:[log in to unmask]>
>> List-Subscribe: <mailto:[log in to unmask]>
>> List-Owner: <mailto:[log in to unmask]>
>> List-Archive: <http://listserv.muohio.edu/scripts/wa.exe?LIST=PERFIGO>
>>
>> Aaron et al,
>>
>> Here goes. While I am sure this response will not be satisfactory to
>> many, this is the best I can say.
>>
>> How Clean Access verifies patches - In most instances, Clean Access uses
>> registry keys to verify patches. Not always though - in some instances,
>> we use file versions, etc. as well. We decide this on a patch-to-patch
>> basis after testing.
>>
>> How Microsoft verifies patches - Its mostly a mystery. Really speaking,
>> something like MSBA is the best way to verify whether a system is
>> correctly patched or not. However, MSBA takes a long time to do its
>> work. The ActiveX scanner from the Windows update website, on the other
>> hand, doesn't take the same approach as MSBA. How can we tell -
>> because, there have been multiple cases where Windows update tells us
>> that there are no patches, except that the DLL file versions show that
>> they are still vulnerable. There has also been an instance where a
>> hotfix required a patch (another KB item) and as long as machines had
>> the "patch", they showed up as not requiring the hotfix itself. So,
>> they are not correct in all instances either.
>>
>> How can we make things better? - if we purely used DLL versions to check
>> things, we feel that the check would be far more accurate than it
>> currently is. However, this will take some time for us to support for
>> multiple reasons - 1) we need to have a faster way of checking since the
>> check/rule size for a purely DLL-based checking would be huge 2)
>> Adequate testing capabilities to support this. We are working towards
>> this but it will take some more time. In the meantime, we try to test
>> and re-test the rules/checks we have to try to ensure minimal flaws.
>>
>> -Rajesh.
>>
>> -----Original Message-----
>> From: Perfigo SecureSmart and CleanMachines Discussion List
>> [mailto:[log in to unmask]] On Behalf Of Rothberg, Aaron
>> Sent: Friday, August 25, 2006 8:19 AM
>> To: [log in to unmask]
>> Subject: Microsoft Windows Update Website
>>
>> I was hoping for a reply from Rajesh with more details regarding the
>> Windows Update website.
>>
>> It would seem to me that while Cisco Clean Access has chosen to review
>> the Registry to identity if a Critical Update has been installed,
>> Microsoft is using a different method for the same verification. This is
>> causing us some pain in that since Microsoft created Windows, I would
>> expect they understand best how to determine if a patch has been
>> installed or not and would tend to trust their website more than a 3rd
>> party. Given in these instances the Microsoft Update Website states a
>> student has all of the Critical Updates, I don't want to have to spin
>> our wheels installing a patch simply to insert a Registry Key to satisfy
>> Cisco Clean Access, when quite possibly the appropriate DLLs and EXEs
>> have been updated and no security vulnerability exists on the machine.
>>
>> Rajesh, can you discuss why Cisco Clean Access uses a different method
>> for verifying patch installation and if Cisco plans to employ the same
>> method of verification that Microsoft uses in a future release so the
>> web page and CCA come to the same conclusion? And also, can you mention
>> why we should be confident that Microsoft's Update website it lying to
>> us and we should believe a vulnerability exists simply because a
>> Registry Key is missing?
>>
>> --Aaron
>>
>> -----Original Message-----
>> From: Perfigo SecureSmart and CleanMachines Discussion List
>> [mailto:[log in to unmask]] On Behalf Of Joseph Haynes
>> Sent: Thursday, August 24, 2006 8:55 AM
>> To: [log in to unmask]
>> Subject: Re: KB913433
>>
>> Apparently that patch is only needed if you have an older version (6 or
>> 7) of macromedia flash installed. CCA Should be checking for both an
>> older version of flash and the patch, not the patch by itself.
>>
>> Does this help?
>>
>> http://support.microsoft.com/kb/913433/en-us
>>
>> Joe Haynes
>> University of Marh Washington
>>
>>
>>>>> "Rothberg, Aaron" <[log in to unmask]> 08/23/06 9:18 PM >>>
>>>>>
>> We're running 3.5.10 and have an interesting problem.
>>
>> We've got a student computer that Microsoft Windows Update website says
>> has all of the Critical Updates, yet continues to fail a CCA check for
>> KB913433, a Flash update. When the student tries to install this update
>> he gets the pop-up, "The version of Macromedia Flash you have installed
>> does not match the update you are trying to install."
>>
>> So the student can't install the update, but CCA won't pass him until he
>> does. Our only way around at this point is to modify the registry. Our
>> helpdesk is a bit concerned at the number of people that may be affected
>> given our recent discovery (and previous posting) that Microsoft Windows
>> Update and CCA seem to disagree in a variety of instances where the web
>> site says the user is good and CCA states updates are still missing.
>>
>> Has anyone seen this issue with KB913433 or the same symptoms with any
>> other Critical Update? Suggestions? Sledgehammers?
>>
>> ...and for the record, are most people in agreement that Microsoft's
>> Update Website looks at DLL versions to determine if a patch is
>> installed or not and thus the discrepancy between CCA and Microsoft
>> saying a patch is missing (CCA) when it has been installed (Microsoft
>> Update website)?
>>
>> Rajesh, can you give us a Cisco ruling on this?
>>
>> --Aaron
>> Helpdesk Computer Tech
>> 603.358.2590
>>
>>
>
> -------------------------------------------------------------------------------
> Simon Kissler [log in to unmask]
> Sr. UNIX Systems and Network Administrator Phone: (219) 464 6773
> Information Technology Fax : (219) 464 5381
> Valparaiso University
> Kretzmann Hall B12
> Valparaiso, IN 46383
> -------------------------------------------------------------------------------
>
> "The great tragedy of science --
> the slaying of a beautiful hypothesis by an ugly fact."
> -Thomas Huxley
>
> -------------------------------------------------------------------------------
>
>
>
|
