On Tuesday 28 July we released guidance and updates to assist developers using our Active Template Library (ATL) to prevent creating controls or components with potential security vulnerabilities. Vulnerabilities in libraries are a rare, but industry wide issue, that requires broad collaboration and action by the community at large to effectively resolve.
Developers who have built controls using the ATL should take immediate action to review their control to identify if it is vulnerable and take appropriate action to rebuild their control using the updated ATL library and distribute a non-vulnerable version of their control to their customers.
If you develop any controls with ATL then please take a look at the guidance on MSDN detailing the steps required to identify and address affected controls. Also, we cover the issue in a Channel9 video.
If the libraries on the end users machines are silently being redirected to the new versions then how come we have to go through this nightmare? Especially for people like me who do not use ATL or MFC.
I'm having a different problem but one that is related. After patching our build machines with the security update (VS 2005) we started having trouble with the setups for our products (generated by InstallShield). Even after I made sure InstallShield was using the updated merge modules for MFC, ATL, etc., when I run the installer it does *not* install the 4053 assemblies (and our applications will not launch). However, after I run the vcredist on the target system the 4053 versions are installed and the application works fine.
This may be more of an InstallShield bug than anything. But how is it that merge modules provided by Microsoft don't seem to be actually gathering in the correct DLLs when the setup is compiled?
Thanks for taking the time to send me more information – it definitely helps us understand your scenario better. Let me walk through your two points to see if I understand them as I still have (yet more) questions:
Re: your point 1) you do not have to have these third party binaries recompiled if you do not want to – you can just keep using the versions you have.
[A couple of sub-points however:]
1) If they have the security issue that the update addresses and are potentially vulnerable then you may want to have them recompiled - but since I do know the specifics I would not know if this would be an issue
2) Regardless of point 1, the third party binaries will probably be rolled forward to running on the new libraries anyhow, if they run on an end-user machines with them installed (via auto-update for example), but this should be no issue. Are the end-user machines some type of dedicated machines without automatic updating?
[End of sub-points.]
Re: your point 2) building on different configurations to those you develop on is again your choice (and given a large organization with many developers occasionally seems inevitable to some degree) – but I am not sure I see the issue here, if the build machines are consistent then they will reference only one version of the libraries and if you ship the redistributable with your application then it will all work – the only issue here I see here is if you do not to ship the redistributable - and that is definitely not a supported scenario.
I should just clarify too, when I say "ship the redistributable", you have a few ways to do this – VC Redistributable, MSMs, app-local and even static linking (although there are some issue with static linking) but all will get the new libraries on to the end-user system.
Let me know if am getting closer to understanding the scenario here?
George and Damien
Your situation (or at least the questions I would ask about it) seem similar to those I asked David but I suspect you will have some different answers (since your end-user systems may be closed box dedicated machines if I read your situation correctly.) Personally I am less familiar with the XPEmbedded scenarios so I may have a few more question for you however.
Re: your comment: Our testers and our XPEmbedded control systems didn't have the update (of course) so they couldn't run.
So I assume you are saying that it does not make sense for you to (and therefore you do not) ship the VC Redistributable (or the new version of it) with your application to these systems? Is that because you have “closed-box” system with the XPEmbedded control systems? If the answer is yes and yes then it may not make sense to have your development machine auto-updating if this will move them out of sync with your target platforms. Would that sound correct? Do your target systems ever update our libraries then? And if so how?
> Could I just uninstall the patch?
Our general advice is to never uninstall Security Update but if you provide a “closed-system” device that does not have access to auto-updating and is sealed then you may be able to determine that an uninstall is safe for you but you need more information than just this to make a decision.
If you have automatic updates turned off on your developer/build machines then you will not see the new CRT (therefore your binaries will not reference it) and all your end-users will just work (many of your end-users will be auto-updated but regardless nothing will break.)
There is no way to install the update without the msp. Not sure why you are seeing an issue installing the patches, is there anything “different” about your setup? (We have tested the install on VS2005 to verify it and it is definitely working for us.) Unfortunately, if you need the Security Update then you probably need the “uber-recompile”.
Feel free to follow up directly if you want, my email is my_first_name at you_know_where (and this is Damien typing )
George and Damien
This fiasco strongly suggests that the only viable model of distributing dynamic CRT is app-local. Anything applied at the machine level is likely to screw things badly.
Hello George and Damien
I think I meet the same problem with David.
I have built something.exe before install this package, and have copied microsoft.vc90.crt.manifest, microsoft.vc90.mfc.manifest, mfc90.dll, mfc90u.dll, mfcm90.dll, mfcm90u.dll, msvcm90.dll, msvcp90.dll, msvcr90.dll to the same directory with something.exe, and put all of them to a custom's pc with neither VC redistributable package nor service pack installed.
I open the something.exe with UltraEdit, and cound find that both the CRT and the mfc version which were referenced are 9.0.30729.1 in the assembly information.
Of course I have defined #define _BIND_TO_CURRENT_VCLIBS_VERSION 1;.
BUT NOW, after installed this update, the new version 9.0.30729.4148 CRT, MFC and so on have been installed in to WinSXS.
After I re-build the something.exe, I will reference CRT 9.0.30729.1 and reference MFC 9.0.30729.4148 and Dependency CRT 9.0.30729.4148.
And something.exe won't work in the custem's pc.
I have try to overwrite the CRT, MFC files with the new version 9.0.30729.4148, but no effect.
Sorry for my poor english, any question please let me know.
Please advise me how to do, thank you very much!
Hi Nicholas, the fact that you're referencing BOTH 9.0.30729.1 and 9.0.30729.4148 CRT in the same EXE means that you haven't rebuilt everything. It's most likely some static library that still hasn't been rebuilt. That's a very common thing for people to miss. They assume that a static lib cannot contain references to a particular version of a DLL, but they can. Also check ALL your intermediate manifests for any references to 762 files.
(sorry, I meant .1 files not 762 files above)
I don't get why you patched the SP1 vcredist_x86.exe on my LOCAL machine... but you didn't patch the vcredist for SP1 on the microsoft website?
We did but I assume the old versions are probably still available online too (is that what you mean?) See this link from above for the entire list of download links: http://www.microsoft.com/technet/security/bulletin/ms09-035.mspx
Our story and comment.
Months of beta testing and everything is going smooth, the day before going to duplication. One minor change is made to program and recompiled and released for internal testing. User emailing to R & D that program won't come up. Look into Vista event log shows side by side conflict. WHY??WHY??WHY?? Where did version 4053 come from... Hunting.. find culprit security update...Duplicator is asking for final release. End user must install release by 8/26/09 or application stops working. What do we do? Not enough time to try suggested changes. The fear of un-installing. Head ache of dealing with a patient with knife pulled out and trying to sew them back together. Not option. Scratching our head what to do to beat the deadline.... Looked under desk. Found old computer taken offline one year ago. No security update installed with VS 2005 SP1. Got the program compiled. Build final release and hand off to duplicator. Ready for FedEx pickup to go to customer. Blood pressure comes down…
Since 2006 8.0.50727.762 was untouched and sent out with our program. Then comes thru a backdoor is a security update that everyone loads due to fear of virus attack and changes our compiler and runtimes. This should have come down thru a service pack and not a security update. People would have been more cautious to load a service pack. Giving others time install it learn about the conflicts and warn other programmer about this. Instead of just blasting it out to the masses in a security update.
Now we think twice about installing those security updates....
Thank you for your information!
My EXE is a very simple, I don't think so there is any library included by it.
BUT I have resolved this issue after the following change:
in the file "C:\Program Files\Microsoft Visual Studio 9.0\VC\include\crtassem.h"
//#define _CRT_ASSEMBLY_VERSION "9.0.30729.1" // to be commented
#define _CRT_ASSEMBLY_VERSION "9.0.30729.4148" // to be added
#define _CRT_ASSEMBLY_VERSION "9.0.21022.8"
Rebuild the exe, and copy CRT & MFC runtime files with 4148 to the same dir with exe, It seems all things work.
Hi Nicholas your workaround works great, the only downsides to it is that it involves changing of Microsoft program files so is hard to track or distribute if you have a large team, also your workaround doesn't work for MFC DLLs, but that's ok for you too because yours is just a simple EXE.
(ignore what I said about it not working for MFC DLLs since you're working with VC2008 not VC2005)