Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

December 2008 VB 6 A security update 5

Status
Not open for further replies.

SBerthold

Programmer
Sep 20, 2002
1,014
DE
From 8 December 2008

"Description of the cumulative update rollup for the Visual Basic 6.0 Service Pack 6 Runtime Extended Files"

A security issue has been identified that could allow an attacker to compromise your Windows-based system running Microsoft Visual Basic 6.0 Service Pack 6 and gain complete control over it. You can help protect your computer by installing this update from Microsoft.

Somehow I missed this, and in "Microsoft Update", it didn't show up under the list of software to update.

Has anyone installed this yet? If so, any known problems?



 
Wow!
Thanks, sBerthold, that's valuable info!
[thumbsup2]

[navy]"We had to turn off that service to comply with the CDA Bill."[/navy]
- The Bastard Operator From Hell
 
Thanks. I have installed this and haven't experienced any problems.
 
The December 9 Update was replaced by a December 30 Update. Check the date on 957924 linked above.

They both break a number of the new-versioned controls, but the bugs won't strike until you try certain operations.

These cannot be uninstalled! Do not install until a tested fix becomes available.

VB6 SP6 Security Update Dec 9, 2008
 
dilettante said:
The December 9 Update was replaced by a December 30 Update. Check the date on 957924 linked above.
That is the review date, not the publish date. The download has a Date Published from 8 Dec 2008 and has files with dates from Nov 2008. (just the kb review date was last on 30 Dec).
Or did I miss something else?
MS kb 926857 30 Dec. 2008 said:
( )
MS08-070: Description of the security update for Microsoft Visual Basic 6.0 Service Pack 6 Runtime Extended Files: December 9, 2008
dilettante said:
They both break a number of the new-versioned controls, but the bugs won't strike until you try certain operations.

Thanks, That is what I was asking for.

dilettante said:
These cannot be uninstalled! Do not install until a tested fix becomes available

Yes, the MS article says that. When I get the time, I will install it on a Virtural PC and see what I can find.
 
That is the review date, not the publish date. The download has a Date Published from 8 Dec 2008 and has files with dates from Nov 2008. (just the kb review date was last on 30 Dec).
That's correct. I goofed. I was imprecise about the Dec 30 date, which is the KB background article about the Dec. 9 Rollup.

We've been trying to fit testing in alongside normal daily workload here for several days now and we're getting a little frazzled. The problem is our "testers" have no idea which applications use which controls, or even less which might use them throughly - excercising most properties and methods.


The other option besides using an OS in a VM (which is safest) is to package using reg-free COM. That way you can just unpack the distribution MSI to get the OCX files and drop them into your isolated assemblies.

With care you could probably also just extract the OCXs and use them to temporarily replace the ones in System32 versioned prior to 6.1.98.12. Then after testing restore your originals.

I haven't noticed any interface signature changes in the 6.1.98.12 or 6.1.98.13 controls, though I have seen others make such a claim.
 
Thank you dilettante (star for you).
What I didn't see from MS, being that they say this update is very critical, is an update for machines where VB6 is not installed.
Nor have I found newer merge files from MS for this - I guess this "critcal" update is left up to the vendors.
 
That seems to be true.

I haven't found a merge module with the new controls (though being busted who wants them?) and there is no obvious blanket patch redist for target machines.

And do you really want them to push these out via Windows Update? ;)

With so many people shipping the controls in isolated assemblies now anyway there is no way Microsoft could update all occurrences. ISVs (or internal maintenance staff) have to do it.
 
Has anyone seen another attempt yet? Maybe Microsoft can blow off a third toe. They still have 8 left.
 
I'm not installing it yet, but views on the following would be appreciated;

1) is this True or False
I'm guessing the proposed 'Upgrade' upgrades the ocxs in the host computer's ..System32 folder.
Assumes the developer is distributing the ocxs in the host computer's ...System32 folder.

2) is this True or False
Unless the installation/ deinstallation of COM stuff has been rewritten for this particular 'upgrade' it seems likely that the upgrade could be reversible if all applicable .ocx files in ..System32 are backed up (maybe unregistered) before upgrade and reinstalled/ reregistered after upgrade.

3) is this True or false
Reverting to an OS Restore Point would 'undo' the upgrade.
 
dilettante said:
And do you really want them to push these out via Windows Update? ;)
,

No, not really at all.

I guess MS wanted us to take the responsibility...not for just the testing and re-distribution, but also for what happens when vendor product XYZ updates, and if and when all other products also using any of the ocxs, break because of our, or someone elses update package...

In otherwords, if MS blew off "a toe or two", then we should also have our toe count Updated as well? ;)

However, we must not overlooking one thing:
We cannot prevent other sources from going through with this update and re-distibuting the files.
Therefore, we cannot just ignore it if we wish.

So, regardless, we are going to have to somewhere and some day live with at least some of the bugs this package may have, depending what was re-distributed, as long as others can, and will blindly be re-distributing applications using and installing some of these ocxs and dlls updates.

Therefore, it is beneficary for all concerned, to test and see just what affects it will have on your products, find possible work-arounds, and be prepared for the worse scenario...

I guess that could be an answer to HughLerwill questions in general, unless they have complete control of the systems concerned.
In that last case then:
1) True, or wherever they are installed.
2) True, I think if you create a reveral process capable of doing it correctly.
3) True, I think if the restore is capable to do this correctly and completely, not just for the OS, but also for the complete system, or drive, including the registry.

(also see: for VB6-VISTA support statement and the files shipped with VISTA, and compare them with the updated files listed in the link pointed to in the OP)
 
SBerthold said:
However, we must not overlooking one thing:
That of course, always was and is the bottom line for any updates outside of our control...
 
The update replaces the controls' CAB files, several VB6 Designers, and a number of standard VB6 controls' OCX/DLLs and DEP files. Some go into System32, others into Program Files\Common Files, etc.

No user should install this package, it is clearly a developer update.


Because this (as many VB6 updates) is an IExpress package it can't be uninstalled via "Add/Remove Programs." You could probably reverse it by manually overwriting all of the new files with old ones though.

As far as I have seen there were no interface signature changes so you shouldn't even have to re-register anything. I have read rumors to the contrary about the interfaces though. So far all of the GUIDs/ClassIds look the same to me though I haven't checked them all.

There just isn't any uninstall option, either on the package itself or via Control Panel.


I agree we have some responsibility here. Certainly we're responsible for updating any applications using private assemblies. I don't plan to proceed with this Update until I have a corrected version of it though.
 
This is where using isolated assembles and reg-free COM can be a blessing and a curse.

If you distribute this way nobody else's product install is going to break your application since you don't use the registered DLLs/OCXs. However if bugs are corrected and security holes filled in... unless you ship an update your application can't benefit even if users update the system copies.
 
Yes of course. That is an option (if the OS is XP >= SP2 or VISTA).

I'll point those interested on reading more about reg-free COM to your TT thread, and an article at devx and msdn:


Here, as msdn:

However, we have many customers still using W2000..., therefore it not an option for me to really consider or pursue at this time.
 
Yes, anyone still supporting Win2K or earlier Windows versions still has to face this head on. Still 16 months until support stops on Win2K anyway.

I still haven't found a more recently corrected Update.
 
Ok. This may have confused some:

#1. ======================================================

...Article 926857
Last Review: December 15, 2008 - Revision: 3.2
Title: "Description of the security update for Microsoft Visual Basic 6.0 Service Pack 6 Runtime Extended Files: December 9, 2008"

...shows 8 VB6 ocxs with dates of 10 Oct. 2008 and versions 6.1.98.12 (one is v.6.1.98.11)

...points in the Introduction section to:
Security bulletin MS08-070,
Title: "Microsoft Security Bulletin MS08-070 - Critical
Vulnerabilities in Visual Basic 6.0 Runtime Extended Files (ActiveX Controls) Could Allow Remote Code Execution (932349)"
Published: December 9, 2008 | Updated: December 15, 2008


...which points to this
VB6 download,
Title: "Microsoft Visual Basic 6.0 Service Pack 6 Security Rollup Update"
References Security Bulletin MS08-070
References Article: KB926857
Date published 12/9/2008
VB60SP6-KB926857-x86-ENU.msi
KB926857
3.4 MB

...But has at the top a reference to a newer article (957924) and update, which is listed under #3 below.

#2. ======================================================

...Article 932349
Last Review: December 16, 2008 - Revision: 4.0
Title: "MS08-070: Vulnerabilities in Visual Basic 6.0 Runtime Extended Files (ActiveX Controls) could allow remote code execution"

...shows 8 VB6 ocxs with dates of 10 Oct. 2008 and versions 6.1.98.12 (one is v.6.1.98.11)

...points in the Introduction section to:
Security bulletin MS08-070,
Title: "Microsoft Security Bulletin MS08-070 - Critical
Vulnerabilities in Visual Basic 6.0 Runtime Extended Files (ActiveX Controls) Could Allow Remote Code Execution (932349)"
Published: December 9, 2008 | Updated: December 15, 2008


...which points to this
VB6 download,
Title: "Microsoft Visual Basic 6.0 Service Pack 6 Security Rollup Update"
References Security Bulletin MS08-070
References Article: KB926857
Date published 12/9/2008
VB60SP6-KB926857-x86-ENU.msi
KB926857
3.4 MB

...and references (#1 above)
Article 926857
Last Review: December 15, 2008 - Revision: 3.2
Title: "Description of the security update for Microsoft Visual Basic 6.0 Service Pack 6 Runtime Extended Files: December 9, 2008"




#3 ======================================================

...Article 957924
Title: "Description of the cumulative update rollup for the Visual Basic 6.0 Service Pack 6 Runtime Extended Files"

...shows about 40 VB6 ocxs and dlls with dates of 13 Nov. 2008 and versions 6.1.98.13 ((one is v.6.1.98.12)

and references "security update 926857" (above) which it includes,

...which points to this
VB6 download for KB957924:
Title: "Microsoft Visual Basic 6.0 Service Pack 6 Cumulative Update"
References Article: KB957924
Date published 12/8/2008
9.6 MB
VB60SP6-KB957924-x86-ENU.msi


...Which I referenced in my OP.
======================================================


What is probably misleading are the published dates of the downloads. The obviously older package with 8 ocxs was published (date published, not date reviewed) one day later than the newer package, which has about 40 ocxs and dlls, and the newer package includes the older package.

So, the download listed under #3 and in my OP seems to be the correct one, though the Publish Date on the download page is one day older.
 
I think you have identified the latest one, but it may be a stretch to call it correct. Someone found a bug in the MSChart20 control (6.1.98.13) and I had no trouble reproducing it.

I almost wonder if Microsoft was being run by interns from November through December. ;-)

The problem impacts VB6, VFP6 and later, Office VBA, ActiveX-based intranet applications, and maybe some others as well. A big enough population of "unsupported" tools, applications, and users that I have hope that we may still see a fix before too long.
 
>but it may be a stretch to call it correct

yes, of course.
What I meant with "correct" was that it appears to be the lastest one and the only one which probably should be downloaded, if one is to be.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top