Issue metadata
Sign in to add a comment
|
Security: Insecure DLL loading by Chrome on Windows 7
Reported by
samit1...@iiitd.ac.in,
Feb 14 2017
|
||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS Chrome browser Windows application is vulnerable to an insecure DLL Loading vulnerability that could allow attackers to perform a DLL hijack thereby allowing arbitrary code to execute on the machine running Chrome. When LoadLibraryEx/LoadLibrary API is called, the DLL is searched for in directories defined by the following DLLSearchOrder: 1. The directory from which the application loaded 2. The system directory 3. The 16-bit system directory 4. The Windows directory 5. The current working directory (CWD) 6. The directories that are listed in the PATH environment variable When the search has reached #5 and #6, an attacker with limited privileges could hijack the search and provide a malicious shcore.dll file which would get loaded by Chrome. The attached PoC video shows a privilege escalation attack by a limited user who places the missing shcore.dll file in a world writable directory (C:\Python27) which is present in the PATH environment variable. Malicious code will execute in the context of the user who is running Chrome, thereby enabling a Privilege Escalation attack if Chrome is launched by an Admin. An attacker could even gain programmatic access to the memory contents of Chrome, and could maintain a persistent Admin level control on the local machine after successful exploitation of this vulnerability. VERSION Chrome Version: 56.0.2924.87 Stable Operating System: Windows 7 Enterprise, Service Pack 1 REPRODUCTION CASE The attached video shows how to reproduce the issue. The shcore.dll was created using: msfvenom -p windows/exec CMD=calc.exe -f dll > shcore.dll I have used Sysinternals utility called Process Monitor to monitor DLLs loaded by Chrome.
,
Feb 14 2017
Mitigation: Specify a fully qualified path when using the LoadLibrary, LoadLibraryEx, CreateProcess, or ShellExecute functions OR Use the LOAD_LIBRARY_SEARCH flags with the LoadLibraryEx function, or use these flags with the SetDefaultDllDirectories function to establish a DLL search order for a process and then use the AddDllDirectory or SetDllDirectory functions to modify the list. (Ref:https://msdn.microsoft.com/en-us/library/windows/desktop/ff919712%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396)
,
Feb 14 2017
As a general rule, DLL replacement is outside of Chrome's threat model; permitting limited users to write to directories in another user's PATH variable is a configuration mistake on the system: https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model- It's unclear whether adopting Microsoft's DLL Loading advice would break anything we care about; it might be a nice defense-in-depth to match other browsers.
,
Feb 14 2017
Thanks for your response. I agree that if an Admin sets the system PATH variable to contain a world writable directory then it is a configuration mistake. However, the intent of the Admin is to get python running quickly. If a Windows application like Chrome does not restrict the sources from where the DLLs it uses are loaded, it is bound to get into trouble. Microsoft tries its best to find the DLL. But I believe the onus is upon Chrome developers to limit locations which they trust to pick Dlls from and directories mentioned in the PATH variable should never be trusted. That said Microsoft does provide preventive measures to restrict the source directories from where a Windows app picks the DLLs. The big question then is why not use these preventive measures? Additionally, with reference to the article you shared; it states that "We consider these attacks outside Chrome's threat model, because there is no way for Chrome (or any application) to defend against a malicious user who has managed to log into your computer as you, or who can run software with the privileges of your operating system user account". In my bug description I am referring to a case where a limited user is able to plant the DLL and an Admin then runs Chrome. So the limited user need not log in as an Admin and neither is the limited user required to run a software with the privileges of Admin's user account. It appears to be a clear case of privilege escalation. In the past Microsoft themselves have accepted such vulnerabilities, for instance CVE-2016-0041. I would be extremely surprised if the Chrome team does not take preventive measures against insecure DLL loading.
,
Feb 14 2017
Please also note that in CVE-2016-0041 - Among the many Microsoft software that tried to search for the culprit phoneinfo.dll; MS Edge was one of them.
,
Feb 14 2017
For what it's worth, sandboxed render processes do appear to call SetDefaultDllDirectories: https://cs.chromium.org/chromium/src/sandbox/win/src/process_mitigations.cc?q=LOAD_LIBRARY_SEARCH+package:%5Echromium$&l=48&dr=C but I wasn't able to find any equivalent calls for the outer browser process. > So the limited user need not log in as an Admin and > neither is the limited user required to run a software > with the privileges of Admin's user account. > It appears to be a clear case of privilege escalation. The privilege escalation occurs at the moment when the limited user is able to copy a DLL to a PATH used by another user (as a result of the configuration mistake). > In the past Microsoft themselves have accepted such vulnerabilities Sometimes. I have submitted many instances of DLL hijacking issues to MSRC (see e.g. https://textslashplain.com/2015/12/18/dll-hijacking-just-wont-die/). Microsoft application teams typically say this isn't an application security bug, while Microsoft's OS team maintains that this isn't a platform security bug. Internet Explorer has patched issues of this nature (http://www.macworld.com/article/1133703/ms_safari.html) while other teams have not.
,
Feb 14 2017
Marking as wontfix as this looks like a physically local attack as per comment 3. elawrence@: if you think there is action that we really do want to take here, please re-open :)
,
Feb 15 2017
Eric, thanks for sharing your experience with Microsoft. Over the years Chrome has earned the reputation of the safest browser in the market and I would appreciate if just like IE and MS Edge, Chrome as well takes remediation steps (at least to be at par with other browsers) to protect the outer browser process. I agree with the fact that Microsoft has been accepting DLL hijacking issues when applicable only to their browsers, which makes this issue all the more relevant for Chrome. I would request you to consider this for the betterment of the product.
,
Feb 24 2017
Hi, Since there is no commitment from Chromium team to fix this issue, I intend to make this vulnerability public on 14th March. This would help Chrome customers realize that their browser may load DLLs from unsolicited directories and as a result arbitrary code could be executed with elevated privileges.
,
May 24 2017
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by samit1...@iiitd.ac.in
, Feb 14 2017