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.
I imagine you're probably already aware of this, but this update is causing issues in the field because people aren't expecting that an ATL security update would silently change the version of the CRT that is referenced by manifests for non-ATL applications. It's also not clear where you get the redistributable for the 4035 build of the VS2005 CRT.
I'm seeing questions about this, too, and people are also wondering whether they can target the 'old' CRT/ATL/MFC runtimes. Any thoughts on that?
I removed this update. Modifying the deployment scripts for all packages would be too much.
> It's also not clear where you get the redistributable for the 4035 build of the VS2005 CRT.
The “4053” redistributable is part of the VS Security Update - I assume you have minor typo when you say 4035 above.
You can also get it from the download center: http://www.microsoft.com/downloads/details.aspx?familyid=766a6af7-ec73-40ff-b072-9112bab119c2&displaylang=en
You can find the VS and VC Redistributable downloads off this page: http://www.microsoft.com/technet/security/bulletin/ms09-035.mspx
George and Damien
The recent ATL Security Update targets two different customer scenarios: 1) end-users and 2) developers. Here an “end-user” can be categorized as anyone who has the VC Redistribute package installed in a standard location (see note below) and which can be installed directly by a user or as a result of installing another product. A “developer” is anyone who has Visual Studio installed. Here is a quick synopsis of what gets installed for each scenario:
a.A new version of atlXX.dll (where XX matches a specific version number) is installed in the Fusion Cache (a.k.a. Windows SxS folder) \Windows\WinSxS\*atl*\
a. A new vcredist.exe - that contains:
1) the latest version of the CRT, ATL, MFC and OpenMP libraries
2) Matching pdbs for the new libraries that support multiple architectures (X86, X64, IA64)
3) And for completeness/correctness, some headers from CRT, ATL, MFC, and import libs
4) New CRT, ATL, MFC, OpenMP libraries in the Fusion Cache (this is different to the end-user experience - see above)
In these scenarios the end-user experience is as small as possible while the developer experience is as compete as possible.
Please note: The standard location can vary based on your operating system but its exact location is immaterial to this description.
After installing this update I notice that I have new Visual C++ headers and libraries. My binaries are now referencing the latest version of the CRTs:
This is of course because I'm using _BIND_TO_CURRENT_VCLIBS_VERSION to specify the latest (previously VS2008 SP1) DLLs. How can I continue to reference the SP1 CRT even after installing this update.
davidjward30 at hotmail
Thanks for taking the time to send us your comment/question. My first question to you would be “why would you want to?” Assuming you deploy the referenced version of the CRT with your application (which is our strong recommendation) then the relevant CRT version would therefore be on the target machine?
That said, you can work around it if you want (caveat emptor), see here for one example of how to do that: http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/
Just for completeness I should point out that VS2005 and VS2008 have different semantics when binding to CRTs, see this post from George for more details: http://blogs.msdn.com/vcblog/archive/2008/05/15/vc-runtime-binding.aspx (these may also be of interest too: http://blogs.msdn.com/vcblog/archive/2008/01/07/channel-9-george-mileka-and-ben-anderson-everything-you-wanted-to-know-about-vc-deployment-but-were-afraid-to-ask.aspx and http://blogs.msdn.com/vcblog/archive/2007/07/02/why-your-application-fails-to-load-after-building-with-a-new-version-of-vs.aspx).
I think you can replace
#define _BIND_TO_CURRENT_VCLIBS_VERSION 1
#define _BIND_TO_CURRENT_ATL_VERSION 1
#define _CRT_ASSEMBLY_VERSION "9.0.30729.1"
#define _MFC_ASSEMBLY_VERSION "9.0.30729.1"
#define __OPENMP_ASSEMBLY_VERSION "9.0.21022.8"
to use the latest version of the ATL DLL and explicitly reference the previous versions of the other DLLs (on my machine there is no SP1 version of the OpenMP DLL, only the RTM version).
It's better to put the equivalent definitions in your project preprocessor settings than in a header file.
I don't think any of this is supported by Microsoft though and I haven't actually tried it myself...
Why do I always have to learn something new when some idiots make a new version of the software? Is it not easy enough to copy everything from the previous working version and LET IT BE as it is! Just improve what is needed but don't alter anything because the work to learn everything again is making everybody angry. We have here already hands full of work with our own programs. We don't want to have anything additional just to use some new version of software! And learn lot of unnessesary changes only because the developers are idiots! KEEP IT STABLE!
What would you think of a car that had to be driven backwards only because some team of idiots want to make changes!?! Nobody would want to use that car! Car manufacturers just change a bit the way the new model looks but keep it the same otherwise. Is it too much to ask to do less and be better!
@Janne: "...Just improve what is needed..." This is a highly subjective point. Your needs might be different than others.
The change from VC2005 to VC2008 to keep binding to the RTM version of the runtime, e.g. was a change which helps to keep software running on the client, even when you update you dev machine to SP1 of VS2008. That was a lesson learned by Microsoft I guess. It could have been better from the start - agreed. But ask yourself, do you qualify to throw the stone?
Thanks for your feedback and sorry for the inconvenience we have caused you. So in general the model here should be relatively straight forward, whenever you build/rebuild your software, you need to ship your binaries (exes/dlls) and the redistributable for the libraries you are built against (i.e. vcredist_x86.exe). This is the reason we have/ship the VC Redistributable and this has not changed recently. We have made changes in how libraries are found on the disc (fusion/sytem32) or which version you target by default (RTM/Current) but the same guidance/process – ship the redistributable for the libraries you are built – stays the same. Is there an issue with this design that does not work in your situation?
Our process involves checkin driven automatic builds of ~100 Visual Studio project files. We have another ~20 projects that are built on demand due to their large size and infrequent modification. Finally, we have prebuilt 3rd party libraries and DLLs that are integrated into the code. We don't have source code to those modules; in fact, we would be hard pressed to convince some of the vendors to give us a hotfix (let alone a new build).
Modifying every source file over this large of a project (including open source projects) is not feasible. Using 4053 and 762 at same time does not appear possible either (there are reports saying that having them in the same manifest is bad and should be fixed). Getting new versions of libs and dlls from vendors (more than 20 in several different countries) is also not something that can be done terribly quickly (especially when you're minimizing change during late stage development). Upgrading the runtime library will require a complete new release cycle/test which will delay the release by at minimum a month. We do NOT use ATL/MFC anywhere but are forced to do this because the CRT runtime is also upgraded.
We have automatic updates disabled and have not applied the patch given the impact. It is also worth noting that some of our developers have had trouble getting the patch to install as it crashes due to missing .msp files. Is there a way to install the patch without all the .msp files or original media? Beyond this, what is the most reasonable way to deploy a patch like this on such a large project? It doesn't look like there are many options without the uber-recompile.
We use VS2005 sp1 with InstallAnywhere (no MSI) with the msv*.dll files and *.manifest files in our directory.
rgreen - at - voxeo.com
This bit me yesterday. I was making one of the final builds of a new version of the application that is running inside one of our lighting control systems. Suddenly, our beta testers around the world started to complain that the new build didn't even start on their computers and lighting control boards! (And since you just get the useless "Invalid configuration..." error message, it doesn't give you much of a hint.)
I almost paniced because we are supposed to go public with this version on Friday this week. After hours of seeking, I realized that there must have been some automatic update on my development machine that replaced the libraries. When making the new build, VS2005 silently started to refer to the new library. Our testers and our XPEmbedded control systems didn't have the update (of course) so they couldn't run.
I find the whole idea of silently changing to a new library version horrible. This happened during the very last days of our beta testing. Even if I know what happened now, I cannot simply throw in a completely new version of the core runtime libraries in the very last minute (looking at the change in the build number, there must be a lot of changes...).
This needs to go through heavy testing before we can start using the new library in a mission-critical system!
It seems like you have little experience in how things are used in the field. Rob Green (above) seems to have pretty much the same experience as I do but on a larger scale. I am sure that there are lots of frustrated users out the now.
Also, I still haven't been able to force the compiler into using the old 762 build of the DLLs. I have tried the various tricks that have been suggested. Could I just uninstall the patch?
"Thanks for taking the time to send us your comment/question. My first question to you would be “why would you want to?” "
1. Echoing others, we have a set of third party libs built against SP1 that we don't want to recompile right now. We want to do this at an appropriate point in the release cycle. For example, in Trunk, not on a stable Branch the day before a release.
2. Currently, our build machines have not had the windows update applied, yet most of our development machines have. You could argue that this is wrong, but I'm sure this is not unusual. All machines have VS2008 SP1 of course.
I really think that this should have been part of a Visual Studio service pack allowing us more control whether to adopt the new CRT.
Anders, yes, uninstalling the patch is possible but strongly not recommended. Just look for KB971090 in your add/remove programs (with "show updates" checked).
Or let me know what parts failed if you try my workaround at the link Damien mentioned above.