The problem with C++ Redists & 3rd Party security patches – II

[German]In part 1 of the article series I had published a note from blog reader Karl (al Qamar) about a problem related to security updates for the Visual C++ runtime libraries (redistributables). Part 2 deals with the e-mail correspondence between Karl and Microsoft.


Asking Microsoft

Karl decided to contact the folks at Microsoft Security Response Center (MSRC) and discuss his findings.

Dear Microsoft Security Team,

in my daily work I find dozens of installations of Windows, no matter which version, whether these are installations of private users or corporate using SCCM or WSUS.

Many Windows systems are still vulnerable and in my humble opinion not perfectly protected because a design flaw.

Mainly C++ Redists. Users will not get the latest C++ Redistributables via Windows Update and on nearly every system old vulnerable C++ Redist dll exist, as main or side-by-side installation.

There is a tool called Sereby All-in-One that will nearly* cleanly delete all C++ Redists and Side-by-Side installations and force installation of the latest one you provide on your Website only.

The current situation is that C++ Redists will only be patched in parts, not removing unpatched and vulnerable Side-By-Side installations.

Refer the attached screenshot how a clean and updated C++ Redist should look like on every Windows Client. I never had any issues to do so on hundreds of systems.

*because of a file version check in his script it happens that some outdated C++ Redists entries will remain in Programs and Features (now Apps and Features).

Visual C++ Redistributables
(Click to zoom)

But even if you clean up the runtime environment on the machines, there is a follow-up problem, which Karl addresses here:

Another problem arises here:

Even though if a system is successfully patched with the most C++ Redists and all other vulnerable versions have been purged, e.g. using All in One Runtime there is still a risk.

Developers tend to include (outdated) C++ Redists and overwrite newer C++ DLLs, some installers like Acrobat DC (classic branch) are so blatantly coded, that they even persist to have old unpatched C++ Redists installed otherwise the MSI installer will fail.

Also on Steam and other platforms many games will install outdated C++ Redists because only since C++ 2013 there are some countermeasures. But for C++ 2005, 2008, 2010, 2012 there are none.

Additionally I have seen many applications that provide their own outdated C++ Redists in the installation directory instead of using those installed in Windows.

This happens across nearly all applications and games around.

In short: Many applications bring their own, often obsolete Visual C++ runtime environments with them and install them in the program folder (instead of using the DLLs already present in Windows). Karl suggests that Microsoft take care of the issue:

It would be great if you can finally address these security issues and push out all C++ Redists to the systems and set rules to devs not to include and install their own C++ outdated redists, they will never ever care of again.

Uninstall all C++ redists and install the latest ones (currently not included in Microsoft Update Catalog, but only on MS Website). Currently WU / WSUS will not apply all security updates available for MS XML or all C++ Redists. I am sure you will get the point when comparing versions in my screenshot to the updates that will be applied via WU.

Secondly also many developers include DLLs like d3dcompiler_47.dll that have been recently patched. Developers don’t care to apply patches on their C++ Redists and Windows should force following:

These inconsistencies also exist for systems that will not be updated from MS XML 2.0 / 3.0 / 4.0 to MS XML 4.0 SP3.

This also affects usage of OpenSSL in the same way, but I see that is out of MS scope.

In the last few paragraphs of his mail Karl deals with the problem of the d3dcompiler_47.dll. This has had to be patched lately for security reasons. The installation of third-party software then causes unpatched variants of these DLLs to come back on the system.


What does Microsoft say about this?

Microsoft has responded via the MSRC team to Karl’s request with the following text:

Thank you for contacting the Microsoft Security Response Center (MSRC). What you’re reporting appears to be a security related bug/product suggestion.
To best resolve this issue please see the following two links:
“Microsoft Product Support Services”
“Search Products accepting bugs or suggestions”

In short: This is not our problem – contact product support or submit it as a bug report under the given links.

Entry in the Feedback Hub

Karl told me afterwards about this entry in the Feedback Hub for Windows 10, where the topic can also be found.

In part 3 there is a solution approach and a FAQ that Karl put together.

Article series:
The problem with C++ Redists & 3rd Party security patches – I
The problem with C++ Redists & 3rd Party security patches – II
The problem with C++ Redists & 3rd Party security patches – III

Cookies helps to fund this blog: Cookie settings

This entry was posted in Security, Update, Windows and tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *