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.
Hello Michael (Valecruz)
So I take it from your comments that you do not ship the “VC Redistributable” with your application – can I ask why not? And what is your process to see that the correct runtimes get on to end-user machines?
Hello! Please, tell me, where can i get current
vcredist_x86.exe for VC2008? Thanks.
you can find it here:
> So I take it from your comments that you do not ship the “VC Redistributable” with your application – can I ask why not? And what is your process to see that the correct runtimes get on to end-user machines?
I think you're missing the point. The problems are that:
1) People didn't know that they needed to deploy a new version of the CRT, because they reasonably expected that an ATL security update only updates ATL, and because they don't equate "I want to protect my machine against security threats" with "I want to be forced to deploy a new version of the CRT and ATL right now." This update installed silently on machines and then left people scratching their heads as to why other people suddenly couldn't run their builds, but they still could.
2) You can't expect everyone to instantly switch dependencies and deployment to a new version. Many reasons have been given already for this, including testing, need to obtain updated libs or installer packages from vendors, need to start a new regression testing cycle, restrictions in patch deployment to end users, etc. Nobody wants to take a dependency change the day before they ship.
In addition, the tools for diagnosing this problem are lacking. The error message displayed to the user on XP systems -- "the application configuration is incorrect" -- is very poor. I spent some time tracking down CRT mixups today and the only way I was able to track down the offender was to run "strings" on each lib and grep the output.
This could have been mitigated if:
- The security update were installed separately from part of the update that affects build processes.
- The part that affects build processes were an optional update.
- The ATL update was labeled to also indicate a CRT update.
- The VC++ Team Blog had a warning about the update BEFORE the portion affecting builds was pushed out.
- The Visual Studio IDE displayed an indicator on the next startup that deployment requirements had changed.
- The linker or manifest tool issued a warning when the merged application manifest references more than one version of the same DLL.
- There were greater awareness as to the manifest mechanism, the symptoms and tools for diagnosing manifest-based load errors, and the CRT rebinding mechanisms.
> So I take it from your comments that you do not ship the “VC Redistributable” with your application – can I ask why not?
We do not ship VCRedist* with our application either - rather we use the merge modules. We do this due to the advice on this very blog that the "VC Redistributable" should only be used for ClickOnce deployment:
'“Click Once” will use a custom built installer package called “VCRedist_<arch>.exe” to install the libraries for you. DO NOT use the VCRedist_<arch>.exe installer packages for any other purpose.' [http://blogs.msdn.com/vcblog/archive/2007/10/12/how-to-redistribute-the-visual-c-libraries-with-your-application.aspx]
Does this statement no longer apply?
Thanks for your posting. My first point here is that when I say "ship the redistributable" (or something similar), I am not advising using one particular method over the others; this from previously in this thread where I said:
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.
All means of “shipping the redistributable” have advantages and disadvantages, my meta-point here is that just that you should ship it one way or another with your application. I will look at the other post when I get in to work and see what guidance we gave there (and why specifically).
Thanks for your follow-up and question – will get back to you as soon as I can.
Sorry for the confusion - I interpreted 'ship the “VC Redistributable”' as a recommendation to ship VCRedist*.exe.
Thanks for drawing my attention to your statement earlier in the thread. I now see that you are actually making a more general recommendation to ship the redistributable at all, without specifying how to do so. This I certainly agree with and we will continue to follow this advice - by shipping the MSMs.
Once again, thanks for your question and pointing me to the previous post. I read what Ben said on the previous post and have two general comments. Firstly, in sprit I think Ben’s post is still consistent with the major piece of advice we have stated here and that is that you always need to deploy/ship the “VC runtime libraries” you depend on with your application and doing this is your first/best means to ensure your application runs successfully on end-user machines (and surely this is the ultimate goal). (Un-)Fortunately you have a couple of mechanisms to do this and need to choose one. My comments on this current post are generally about trying to find reasons why people prefer not to (or cannot) follow this guidance (and to be clear I am sure there are valid reasons, I just want to capture them and their scale, I am not saying that such reasons would never exist.)
Secondly, as you can see form the other posting, Ben’s (and therefore our) guidance at the time was to prefer one method (MSMs) over others but again he speaks of advantages and disadvantages of all the different methods provided. You can also see on the thread that Stephan replied said that he preferred a different method to Ben (and I see Phaeron and others replied too with different opinions – nice to see Phaeron is still active on our blog.) The decision needs to be made by individual developers based on their application’s/user’s requirements/configurations – and I think that is really the best/only advice. Now to be clear (and for those who want me to take a stand), my personal preference, which I guess subliminally comes through when I post through the terminology I use, is definitely for VCRedist as the default, but of course I would not claim that this is the best/only solution in all cases. With the benefit of a few years experience now, I feel that MSMs have become less attractive and VCRedist more attractive for a few reasons: 1) VCRedist is easier for you to deploy to your customers if we make a change (you just give them the new VCRedist and they install – there is no repackaging for you to do), 2) we can target VCRedist with our updates since it is identified as an installed MS product on end-user machines and 3) our concern that customers would (potentially erroneously) uninstall VCRedist and thereby break applications depending on it has, to the best of our knowledge, never really materialized.
Redistribution issues aside, I think Michael's post on August 21 and Phaeron's post on August 26 hit the nail on the head.
In my industry, development environments and tools versions are under strict configuration management and control. The prospect that our compilers can be updated at any time without our knowledge or consent creates a configuration management nightmare.
Although I have Windows Automatic Updates disabled on my PC, our IT department forces anything labeled as a security patch through Landesk.
The decision to deploy these fixes as a Windows Update instead of a Visual Studio Service pack was an unfortunate one.
Nevertheless, we are where we are.
Could you please advise as to how I can prevent these silent updates from taking place in future.
Thanks and regards.
As everybody else here we also "suffered" from this particular security patch.
This currently keeps us from delivering service packs for our product, since InstallShield does not provide an updated merge module.
So I decide to uninstall this patch as of now.
Is there a way to prevent this particular patch to be reinstalled again via auto update?
I don't want to turn off auto update in general..
Thanks and regards,
Frank you can hide an update just by clicking on it and hiding it in Windows Update. Or if you're in a corporate enviroment you can do something similar at the server level in WSUS.
P.S. I'm still getting around 100 hits a day on average on my blog for the workaround so it shows that there's still relatively strong interest in avoiding problems relating to this patch.
Hello George and Damien and also Ted,
I want to emphazise the point, that this update should have been released as a Service Pack to give the customers more control.
We also where hit by the update only days from a release with man-month of testing already done. We cannot just jump to a changed framework now.
Is uninstalling the kb971090 patch really safe? Regarding the system beeing the same as before, not the security issues.
Hi Wolfgang, I can tell you that from a "system being the same as before" perspective, that uninstalling the patch is safe, as I had to do this on around 10 machines that inadvertently received the patch before I caught it at the WSUS level, and I've had no problems at all on those machines since uninstalling.
I ran the Uninstall from Add/Remove programs and restarted windows.
"About Visual Studio" still reports the ATL security updates as being installed.
Moreover, the embedded manifests in the binaries I build under Visual Studio still reference runtime library version 4053 instead of 0762.
> This currently keeps us from delivering service packs for our product, since InstallShield does not provide an updated merge module.
Thanks for sending this question on to us. I assume there may be a typo in the sentence above, InstallShield does not provide the updated MSMs, we (VC) do. And the update does provide these, the location on your machine should be something like:
C:\Program Files (x86)\Common Files\Merge Modules
Let me know if they do not exist after you install.