Das Problem mit C++ Redists & 3rd Party Sicherheitspatches–Teil 2

In Teil 1 der Artikelreihe hatte ich einen Hinweis von Blog-Leser Karl (al Qamar) auf ein Problem im Zusammenhang mit Sicherheitsupdates für die Visual C++ Laufzeitbibliotheken (Redistributables) veröffentlicht. In Teil 2 geht es um die E-Mail-Korrespondenz zwischen Karl und Microsoft.

Bei Microsoft mal nachgefragt

Wenn man auf ein solches Problem stößt, ist es nicht ganz unflott, schlicht bei Microsoft nachzufragen. Speziell Firmenkunden haben da ihre Kanäle. Karl hat das Microsoft Security Response Center (MSRC) mit dem Thema kontaktiert und folgende Hinweise gegeben.

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.

Für nicht englischsprachige Leser/innen: In seiner täglichen Praxis stößt Karl auf dutzende Windows-Installationen, Privat-Rechner und Firmensysteme, auch mit SCCM oder WSUS verwaltet. Und dort stößt er auf das in Teil 1 erwähnte konzeptionelle Problem, dass als C++ Laufzeitbibliotheken auf dem System verbleiben. Er schreibt dazu:

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).

(Zum Vergrößern klicken)

Aber selbst, wenn man die Laufzeitumgebung auf den Maschinen bereinigt, existiert ein Folgeproblem, welches Karl hier adressiert:

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.

Kurz: Viele Anwendungen bringen bei der Installation ihre eigenen, oft veralteten Visual C++-Laufzeitumgebungen mit und installieren diese ggf. im Programmordner (statt die bereits in Windows vorhandenen DLLs zu verwenden). Karl schlägt vor, dass sich Microsoft um das Thema kümmert:

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 den letzten Absätzen seiner Mail geht Karl noch auf das Problem des d3dcompiler_47.dll ein. Dieser musste in letzter Zeit immer mal wieder aus Sicherheitsgründen gepatcht werden. Die Installation von Dritthersteller Software führt dann dazu, dass wieder ungepatchte Varianten dieser DLLs auf das System kommen.

Was sagt Microsoft dazu?

Microsoft hat in Gestalt des MSRC-Teams auf Karls Anfrage mit folgendem Text geantwortet:

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"
<http://support.microsoft.com/common/international.aspx>
"Search Products accepting bugs or suggestions"
<http://support.microsoft.com/gp/contactbug/>
Thanks,
Tyler
MSRC

Kurz und knapp: Das ist nicht unser Problem – kontaktiere den Produkt-Support oder speise dies als Bug-Report unter den angegebenen Links ein.

Eintrag im Feedback Hub

Karl hat mich im Nachgang auf diesen Eintrag im Feedback Hub zu Windows 10 hingewiesen, wo das Thema auch zu finden ist.

In Teil 3 gibt es einen Lösungsansatz und eine FAQ, die Karl zusammen gestellt hat.

Artikelreihe:
Das Problem mit C++ Redists & 3rd Party Sicherheitspatches – Teil 1
Das Problem mit C++ Redists & 3rd Party Sicherheitspatches – Teil 2
Das Problem mit C++ Redists & 3rd Party Sicherheitspatches – Teil 33

Ähnliche Artikel:
Windows 7/8.1/10: Fehler Side-by-Side-Konfiguration ungültig