Microsoft Visual Studio C++ Runtime installers were built to fail
Redmond created executable installers with vulnerable tools
Updated Security researcher Stefan Kanthak claims the Microsoft Visual C++ Redistributable for Visual Studio 2017 executable installers (x86 and x64) were built with insecure tools from several years ago, creating a vulnerability that could allow privilege escalation.
In other words, Redmond is distributing to developers executables that install its Visual C++ runtime, and these installer programs are insecure due to being created by outdated tools. They can be exploited by malicious software to execute arbitrary code. It's not the end of the world – it's more embarrassment than anything else, due to the reliance on out-of-date tools.
In a Full Disclosure advisory this month, Kanthak did not mince words. "Microsoft builds [its] CURRENT executable installers from outdated CRAP and dares to ship them to hundreds of millions of customers, where their well-known vulnerabilities can be exploited!" he wrote.
The crap Kanthak is referring to happens to be v3.7 of the WiX Toolset, an outdated release of the open source software used to build Windows installation packages.
Back in January 2016, WiX distributor FireGiant – co-founded by Rob Mensching, who created WiX back in 1999 at Microsoft – published details about the release of WiX v3.10.2, a security update to address a DLL hijacking flaw affecting prior versions of the software.
DLL hijacking involves malware tricking applications into loading malicious library files when the executable runs and thus commandeer the software. Installers are particularly vulnerable because they tend to be downloaded into the Downloads directory next to a lot of other files.
When a vulnerable program runs and searches for a system library to load, it can end up loading a malicious DLL by the same name in its directory before the legit library is found – and that's basically how DLL hijacking works.
"A website that delivers malware can, depending on your browser and its settings, automatically download a DLL to your Downloads folder," FireGiant explains. "If the DLL is named the same as a system DLL that your bundle loads, Windows loads and executes the malware in the Downloads folder instead of the DLL in the Windows system folder."
The firm credited none other than Kanthak for disclosing the issue.
In an email to The Register, Kanthak said, "It's a local attack. It becomes a remote attack if an attacker is able to (ab)use your web browser to perform a 'drive-by' download of one of the DLLs typically side-loaded by executable installers."
Kanthak said he disclosed the issue to Microsoft, as he has multiple times for related flaws over the past two decades. He added that all versions of Windows are potentially vulnerable to this type of attack because the module loader searches DLLs in the Applications directory first.
According to Kanthak, Microsoft's installer was published 10 weeks ago and digitally signed 11 weeks ago, but the executable itself was built on February 13, 2015 – 3.5 years ago – with Visual Studio 2010, for use on Windows XP and newer versions of Windows NT. He points out that Microsoft stopped supporting Windows XP ten months earlier.
Asked about this, Microsoft said it patched the issue in its August security update last week. "Customers who apply the updates, or have automatic updates enabled, will be protected from CVE-2018-0952," a Microsoft spokesperson said in an email to The Register.
But Kanthak insists Microsoft is wrong. He said, "Whatever Microsoft said: It's COMPLETE BULLSHIT, and a BLATANT LIE! CVE-2018-0952 fixes an UNRELATED vulnerability in Visual Studio. THERE IS NO FIX FOR INSTALLERS BUILT WITH WIX TOOLSET!" [His capitals - Ed]
Kanthak said he informed Mensching at FireGiant about this problem three years ago. "He contacted me again just some weeks ago, asking for help: All his fixes don't stop this type of attack," he said.
The Register tried to reach Mensching at FireGiant to confirm this but we've not heard back. ®
Updated to add
A Microsoft spokesperson subsequently clarified that there was some internal confusion regarding the vulnerabilities at issue, and that the August patch does not address the reported problem. We’re told, however, that users installing Visual Studio 2012 and current versions are not affected. Anyone who fetches and runs the installers separately, though, is, we understand.
Also, after this story was published, Rob Mensching, CEO of FireGiant, told The Register:
FireGiant takes its leadership role in the WiX community and our commitment to corporate customers seriously. We’ve addressed all security issues as they were discovered. At this time, we believe all security issues reported by Mr Kanthak and others were mitigated in the WiX Toolset releases last year.
Mr Kanthak recently contacted us about some Microsoft products built with old versions of the WiX Toolset. We are discussing with him the mitigations in the latest WiX Toolset that secure it against known vulnerabilities.
As for Visual Studio using an old version of the WiX Toolset, while many large organizations are FireGiant customers, the Visual Studio organization in Microsoft isn’t one of them. Visual Studio needs to be responsible for integrating fixes in tools they use.