eEye Digital Security

In the Blink-Personal Vulnerability Assessment Report, I have four, high-risk items titled the above -- one for each of comct232, mscomct2, msdatgrd, msmask32 -- all citing MS08-070, KB932349, and Secunia Advisories 26534 and 31498.  I found these 4 names as .ocx files in my Windows\system32 folder.  I read where these are Microsoft Visual Basic 6.0 Runtime Extended Files (ActiveX Controls) which are distributed by developers with their VB6 applications.  These might well also have come OEM with the computer (?).  The date of the one I checked was 1998 and, using Notepad, it looked to be something straight from Microsoft with copyright notice and version number.  The Microsoft-Update application will not offer an update that addresses these items in any way.  Using either MS08-070 (and looking in FAQ’s) or the link (to Microsoft) in the Secunia advisories results in the same download, the “Cumulative Update for Microsoft Visual Basic 6.0 SP6 (KBnnnnnn)” where nnnnnnn depends on the link used.  I do not have MS Visual Basic 6 on my computer and sure enough, when I went to install either download I got the message, “In order to install Cumulative Update for Microsoft Visual Basic 6.0 SP6 (KBnnnnnn) you must have Microsoft Visual Basic 6.0 Product installed”.  This download appears to be for the developer so that his/her future products do not have the vulnerability.  So I still have these vulnerabilities on my computer, and they are of unknown use.  What now?

Does anyone have any thoughts?

What OS and service pack are you using?

 WinXP Pro SP3.

Is the use of kill-bits set by the user required? I refer to
http://www.msisac.org/advisories/2008/2008-041.cfm about 2/3 of the way down, using http://support.microsoft.com/kb/240797 .

I have the same issue....have seen it on three separate scans this week. Am wondering if manually extracting the files from the Microsoft update and then replacing the old .ocx files would break anything.

A bit off-topic, but looking at the new "comct232.ocx" file from the Microsoft update, it has a date of "October 10, 19108" (?)

 Me too.  I'm getting a problem with mswinsck.ocx being the wrong version but I don't have Visual Basic 6.0 or any of the other listed vulnerable programs installed.  Also no update required by Microsoft Update when I checked:

Microsoft Visual Basic 6.0 ActiveX Runtimes Code Execution (932349) - Mswinsck

Finding info...

I'm running Server 2003 with all the latest service packs and updates.  Please tell me someone is tracking this down because I also have about thirty more similar findings on my XP workstations.  Is this a false positive?  If not, what can I download/install to get rid of all these supposed errors with my non-existent Visual Basic install?

Pierce

I'm running Server 2003 with all the latest service packs and updates.  Please tell me someone is tracking this down because I also have about thirty more similar findings on my XP workstations.  Is this a false positive?  If not, what can I download/install to get rid of all these supposed errors with my non-existent Visual Basic install?

There is some piece of software on your system using a vulnerable version of this control.  Microsoft makes reference to contacting your software vendor about recieving updated versions.  Unfortunately, it can be difficult to track down what applications are using this file since it is a shared control.  Kill-bits will deter it from being instantiated within IE, however it is still a vulnerable version of the control and any application using it could be at risk.  If you can't track down the software that is using it or the vendor, you can either unregister the control and remove it from the system -or- you can extract the file from one of the security updates and replace the old version with the new one (though could potentially cause some applications to not function properly, so I would suggest if you take this route, to backup the old version in a zip file -- for good measure -- and restore the old version if the new one causes any issues.).

I had the same issue this week on an accountant's HP Pavilion laptop with Vista Home Premium SP1.  

I thought it was because his update of Quickbooks Pro 2008 was corrupted  - that maybe it was the source of the VB6 files.  But after correcting the problem - updating his QBPro, QB Premiere Multicurrency and Simply Accounting - the Microsoft hotfix that rhkohl mentions gave me the same error message of having no VB6 to patch.

I even gave the system several thorough registry cleanings and junk file cleanups with CCleaner and other tools I have.

I think nomuus (see above) has it.  I have an ancient accounting application (from 1998 - it is QuickBooks Pro 5) that I have customized to fit my needs, and there is no need to upgrade.  I am guessing that this may be the application that initially installed, and uses, these controls based on what I can fathom of their nature from the information in the Secunia advisories.  So long as I do not go out on the internet from that application, assuming my guess is right, wouldn't I be ok?  Any thoughts?

Perhaps not going out on the internet from any old application might be a good rule of thumb.

Ziad:

I had the same issue this week on an accountant's HP Pavilion laptop with Vista Home Premium SP1. 

I thought it was because his update of Quickbooks Pro 2008 was corrupted  - that maybe it was the source of the VB6 files.  But after correcting the problem - updating his QBPro, QB Premiere Multicurrency and Simply Accounting - the Microsoft hotfix that rhkohl mentions gave me the same error message of having no VB6 to patch.

I even gave the system several thorough registry cleanings and junk file cleanups with CCleaner and other tools I have.

The patch will not install because it is meant to be used by the vendor who distributes their applications built with VB6 runtimes.

rhkohl:

I think nomuus (see above) has it.  I have an ancient accounting application (from 1998 - it is QuickBooks Pro 5) that I have customized to fit my needs, and there is no need to upgrade.  I am guessing that this may be the application that initially installed, and uses, these controls based on what I can fathom of their nature from the information in the Secunia advisories.  So long as I do not go out on the internet from that application, assuming my guess is right, wouldn't I be ok?  Any thoughts?

Perhaps not going out on the internet from any old application might be a good rule of thumb.

You are right in that old applications will use old versions.  However, you could still be attacked even if you do not access the internet with that application.  These VB controls are ActiveX's, which means that any capable application could instaniate the control- which is also true for any other ActiveX control.  For example, let's say you visit a malicious website from Internet Explorer, the website could potentially load a vulnerable ActiveX that is installed on your computer.  It could then be exploited to run arbitrary code on your system (e.g. code that downloads and installs a trojan).  If you are an administrator on the computer, this means that the arbitrary code being run on your computer could do anything that an administrator could do, such as adding users, installing drivers (or rootkits that are drivers), etc.

But, Don't worry, Blink will protect you.  ;-]

MS08-070 (http://www.microsoft.com/technet/security/Bulletin/MS08-070.mspx) describes these in its FAQ best.  To summarize, Microsoft is basically saying that if a vendor (developer) using Visual Basic 6.0 for their application development uses the VB6 extended runtimes, then it is their responsibility to update their Visual Basic 6.0 Development Environment with the patch, rebuild the application with the patched runtimes, then redistribute the updated application to their users.  In a nutshell, MS is saying if you built a program with VB6 extended runtimes then it is up to you to fix it not your users.  Below I've commented on parts of the MS08-070 FAQ.

What are the Visual Basic 6.0 Runtime Extended Files? 
The Visual Basic 6.0 Runtime Extended Files include select ActiveX controls, libraries, and tools delivered with the Visual Basic 6.0 Integrated Development Environment (IDE) media and as an online release. Typically, either Visual Basic 6.0 IDE or Microsoft.com installs these files on the development system. The developer then redistributes these files with their applications. Although, as of April 8, 2008, support for Visual Basic 6.0 IDE has ended, Microsoft still offers support for select runtime extended files that are distributed with applications. For more information on support for the Visual Basic 6.0 Runtime Extended Files, please see Support Statement for Visual Basic 6.0 on Windows Vista and Windows Server 2008.

Basically what this is saying is that a developer using VB6 to make their applications will redistribute the Runtimes with it.  Visual Basic 6 development environment updates have technically ended, but (I'm commentating here...:) due to the sheer volume of developers/vendors who use it and its extended runtimes for their programs, we're (Microsoft) releasing an update for these vulnerabilities.

I am a third-party application developer and I use the ActiveX control in my application. Is my application vulnerable and how do I update it? 
Developers who redistribute the ActiveX control should ensure that they update the version of the ActiveX control installed with their application by downloading the update provided in this bulletin. For more information on best practices on redistributed component use, please see Microsoft Knowledge Base Article 835322 and Isolated Applications and Side-by-side Assemblies.

This is saying, YES, if a developer redistributes a vulnerable component with their program then the vendor/developer needs to update the version that was initially distributed.  Third-party application developer refers to any vendor or developer who uses VB6/Foxpro/etc to build their application (for example, as described above, Intuit Quickbooks).

Why does this update address several reported security vulnerabilities? 
This update contains support for several vulnerabilities because the modifications that are required to address these issues are located in related files. Instead of having to install several updates that are almost the same, customers need to install this update only.

I am using an older release of the software discussed in this security bulletin. What should I do? 
The affected software listed in this bulletin have been tested to determine which releases are affected. Other releases are past their support life cycle. To determine the support life cycle for your software release, visit Microsoft Support Lifecycle.

It should be a priority for customers who have older releases of the software to migrate to supported releases to prevent potential exposure to vulnerabilities. For more information about the Windows Product Lifecycle, visit Microsoft Support Lifecycle. For more information about the extended security update support period for these software versions or editions, visit Microsoft Product Support Services.

The updates address multiple vulnerabilities and the patch is a collective update for all affected components.  Microsoft tested the affected releases, including the development environments (which account for the majority of third-party redistributed runtimes).  Persons using affected software should update to resolve potential vulnerabilities.

nomuus, thanks.  I understand that Microsoft expects those that distributed applications with (what are now known to be) insecure VB6 runtimes, to redistribute patched versions of their applications.  But I am guessing that that is not going to happen in my case.  (I believe I have a better guess at the application involved.)   Consider that you can now have killbits in IE for all 4 ActiveX controls of my first post.  (They are all 4 described in MS08-070 and the new Microsoft Security Advisory (960715) [10 Feb 09] says killbits for all ActiveX controls in MS08-070 are in the updates of http://support.microsoft.com/kb/960715 .)  If you install those killbits and now only go out onto the internet in a Limited Access User Account (WinXP Pro SP3), excepting only for those updates, like Blink, where you have to go out with administrator privileges, shouldn’t you be pretty safe, especially if you avoid going out on the internet from within old applications?

Installing the killbits of KB 960715 (see just above) are said to make some Visual Basic programs "toast" (see http://askwoody.com/viewnews.php , near the end of the 18 Feb 09 posting).  The details will be out in the Windows Secrets Newsletter of 19 Feb 09.  My VB application, Grab It! XP, seems to work fine with the killbits installed, but I do not use it through IE.

 just to verify... there is no fix for this category 1 vulnerability?

nihonmike:

Aside from getting the person/vendor(s) who furnished you the application(s) that uses(use) these vulnerable ActiveX components to redo his/her application(s) with the new, non-vulnerable ActiveX components, to check that(those) out, and to furnish that(those) to you to replace what you have [which assumes, as nomuus says (01-23-2009), that you can figure out which applications you may have that use these .ocx files that are just sitting in a systems folder on your computer], you are on your own, and the risks you take and the policies you set up are apparently up to you.  Here is stuff I found when researching this:

1. Said to be capable of disabling/enabling any ActiveX Components:  http://www.nirsoft.net/utils/axhelper.html .

2. According to Microsoft, you can keep the vulnerable ActiveX components from being activated through Internet Explorer by setting appropriate killbits:  http://www.microsoft.com/technet/security/advisory/960715.mspx  &  http://support.microsoft.com/kb/960715  .  This may break some of these applications on your computer (see for example the first part of  http://accessblog.net/2009/02/kb960715-ie7-is-breaking-access-apps.html#c2853757604288373225  and Windows Secrets Paid Newsletter of 2/14/2009).  [In my case, my application (rather, what I think is my germane application) did not break.]

3. Said to be capable of disabling/enabling the killbits for any ActiveX Components in Internet Explorer:  http://www.nirsoft.net/utils/acm.html .

4. Perhaps you could try getting the new .ocx files via the process given in WORKAROUND: on  http://accessblog.net/2009/02/kb960715-ie7-is-breaking-access-apps.html#c2853757604288373225 , but I would be sure to follow the suggestion of "nomuus" made on 01-23-2009 in ( )'s above, as these new ActiveX components cannot be identical to the old ones and so the application(s) using them may or may not work.

5. If the application in which you are going to use the new components in (4.) is on a webpage, you apparently have another problem, see  http://blogs.msdn.com/askie/archive/2009/02/20/certain-vb-controls-no-longer-display-on-web-pages-after-installing-kb960715.aspx .

Good Luck.

Thank you rhkohl for spelling it out for me.

I conquered this bad boy at least a week ago and heres what I did to fix it, verfieid it on other machines as well

#1 goto & DL http://www.microsoft.com/downloads/details.aspx?familyid=E27EEBCB-095D-43EC-A19E-4A46E591715C&displaylang=en

#2 Open command prompt and execute the following command to extract the files:

msiexec /a PathToMSIFile /qb TARGETDIR=DirectoryToExtractTo

Example: Save MSI to C:\download. Extract the files to C:\vb-files.

msiexec /a C:\download /qb TARGETDIR=C:\vb-files

#3 search c:\ for mswinsck.ocx, replace that with what you just extracted.  rescan with retina. done.  hope that helps