Microsoft Visual C++ DLL Hijacking
Posted on 17 May 2016
Dear Sir or Madam, I found a DLL hijacking vulnerability in your Microsoft Visual C++ 2010 Redistributable Package and Visual C++ Redistributable for Visual Studio 2015. Recently a lot of DLL hijacking issues in popular software was revealed. (https://packetstormsecurity.com/files/author/6137/) So I tested your Visual C++ 2010 Redistributable Packages from 2010 and the latest from 2015. I downloaded vcredist_x86.exe from https://www.microsoft.com/en-us/download/details.aspx?id=5555. This is the version from 2010 and as you see it is still downloadable. And vc_redist.x86.exe from https://www.microsoft.com/en-us/download/details.aspx?id=48145 (choosing the x86 version). This is the version from 2015. All tests were done on Windows 7 x86. The security vulnerability is well-documented and also described in docs by Microsoft. Here are a few sites: * https://capec.mitre.org/data/definitions/471.html * https://technet.microsoft.com/en-us/library/2269637.aspx * https://msdn.microsoft.com/en-us/library/ff919712.aspx * https://msdn.microsoft.com/en-us/library/ms682586.aspx * http://seclists.org/fulldisclosure/2015/Nov/101 So when the user downloads these executables (with a web browser) they are usually saved in the "Downloads" directory. If there is a malicious DLL inside it (e.g. by tricking the user to download it via Social Engineering) this can be executed by your installers. More information about the "download folder planting" here: * https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html * http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html * http://seclists.org/fulldisclosure/2012/Aug/134> So I tested your installers and these are the DLL files it loads and executed from the application directory (which is in most cases the Downloads directory as explained above): vcredist_x86.exe: * dwmapi.dll * CRYPTBASE.dll * cryptdll.dll * CRYPTSP.dll * feclient.dll vc_redist.x86.exe: * Cabinet.dll * msi.dll * version.DLL * CRYPTBASE.dll * feclient.dll * WindowsCodecs.dll * dwmapi.dll * PROPSYS.dll * ntmarta.dll * CRYPTSP.dll * RpcRtRemote.dll * apphelp.dll * Secur32.dll * SSPICLI.DLL * MPR.dll ~~ Proof of concept/Steps to reproduce ~~ I only use one DLL to show that it is exploitable. 1. visit http://home.arcor.de/skanthak/sentinel.html, download http://home.arcor.de/skanthak/download/SENTINEL.DLL and store it as dwmapi.dll in your "Downloads" directory; 2. download both installers (vcredist_x86.exe and vc_redist.x86.exe) and store them in your "Downloads" directory; 3. run the two installers from your "Downloads" directory; 4. notice the message boxes displayed from the DLL placed in step 1. I have created a video, which shows this: * webm: https://mega.nz/#!aZYz0IIR!a_ycfhC10WGCfP-WArlRmEzLj-BVPr9-xDn8UfbtnrU * gif: https://mega.nz/#!jMR1hKLJ!vcaw-PypYm-nh2EDGfFrbxZuoOGm_fYX01NGtGOYyyo Due to the application manifest embedded in the installers which specifies "requireAdministrator" the executable installer is run with administrative privileges ("protected" administrators are prompted for consent, unprivileged standard users are prompted for an administrator password); execution of the DLLs therefore results in a privilege escalation! Additionally I noticed that vc_redist.x86.exe is copied to the temporary directory. The path is like this: > %temp%<GUID>.beVC_redist.x86.exe This should generally be avoided as %temp% is another unsafe directory, writeable by users without admin privileges. So when the file is placed there the same DLLs may be planted there or even the exe file itself may be replaced. I did not verified whether this is possible and is another vulnerability, but it is at least bad practise. All this information is treated as strictly confidential and no other person knows about the issues I discovered. I have not submitted this information to anyone. Until the issue is resolved I will not tell anyone of this issue and keep it secret. However if you do not respond during 90 days or fix the error 90 after your first response I may make this information public. This helps to protects your users. However I hope I do not have to do this and cooperation from your site would be very much appreciated. Best regards, <privat> ----- Timeline: * 2016-02-16: send * 2016-02-16: > We are aware of the reports of binary planting in the > application directory (e.g. "Downloads" Folder). At this time, binary > planting in the application directory does not meet the bar for > security servicing by MSRC. For all other binary planting issues we > still service them through MSRC security servicing. > > [links to docs included] Based on the provided link [Definition of a Security Vulnerability](https://technet.microsoft.com/library/cc751383.aspx)] I explained why this is a vulnerability and asked what's the difference "between binary planting in the downloads folder compared to another folder?" * 2016-02-16: > This is a long standing and well known by Microsoft. Binary > planting in the application directory does not meet the bar for > security servicing as I mentioned previously. > > [links to docs included] Again replied and asked "what folder does it have to be loaded to 'meet the bar for security servicing'?" Showed that the linked docs do not answer my question. Me: > Fact is in your applications you do not followed your own > recommendations! That's why there are these issues... * 2016-02-17: > The difference is that the DLL would not be in the same folder > as the program that is being ran. The "Current Working Directory-based > Attack" would be an example of binary planting outside of the > application directory. https://www.owasp.org/index.php/Binary_planting Agreed and asked what to do now: > 1. Will it be fixed? > 2. Should I contact someone else about this issue? > 3. Can I get some other "servicing" for this bug? * 2016-02-17: > Teams are well aware of this issue and working on solutions but there is no ETA on fixing there are many scenarios that must be accounted for. There is no further action that can be taken regarding this issue at this time. * 2015-05-16: report published
