Abstract
A DLL side loading vulnerability was found in the Flash version that ships with Windows. This issue can be exploited by loading the Shockwave Flash object as an embedded OLE object. When instantiating the object Windows will try to load the DLL spframe.dll from the current working directory. If an attacker convinces the user to open a specially crafted (Office) document from a directory also containing the attacker's DLL file, it is possible to execute arbitrary code with the privileges of the target user. This can potentially result in the attacker taking complete control of the affected system.
See also
- SFY20151201: There's a party in OLE, and you are invited
- ms15_132_dll_sideload.rb
Tested versions
This issue was successfully verified on Windows 10 + Office 2013 32-bit.
Fix
It appears that this issue has been resolved by the security updates for Adobe Flash Player of November 2015 (version 19.0.0.245 or later, APSB15-28). The initialization code has been changed in this version. Currently, the DLL spframe.dll is only loaded if Flash is started from Microsoft Edge. In all other cases, Flash tries to load ieframe.dll instead of spframe.dll. ieframe.dll is located in System32, which is searched before the current working directory, preventing side loading of this DLL.
Introduction
OLE is a technology that enables an application to create compound documents that contain information from a number of different sources. For example, a document in an OLE-enabled word processor can accept an embedded spreadsheet object. Unlike traditional "cut and paste" methods where the receiving application changes the format of the pasted information, embedded documents retain all their original properties. If the user decides to edit the embedded data, Windows activates the originating application and loads the embedded document.
OLE objects are loaded via a CLSID or indirectly via a programmatic identifier (ProgID). The CLSID is used to look up its associated DLL in the Windows Registry. In order to check if the provided CLSID is in fact an OLE object, this DLL needs to be loaded in memory first, even if the CLSID is not really an OLE object. Since the DLL may not be designed to be loaded this way, loading it can introduce security issues like side loading of malicious DLLs.
Vulnerability details
It was discovered that the Flash version that ships with Windows is affected by DLL side loading. Loading the Shockwave Flash object (CLSID {D27CDB6E-AE6D-11cf-96B8-444553540000}) as an OLE object will result in Windows trying to load the DLL spframe.dll from the current working directory.
It appears that the Shockwave Flash object loads various DLLs using a relative path depending on how it is loaded (eg, in a browser, in an document). When embedded as an OLE object in an Office document, Shockwave Flash will load spframe.dll using a relative path.
Figure 1: spframe.dll is loaded from the current working directory
An attacker can exploit this issue by convincing a target user into opening a specially crafted (Office) document from a directory containing the attacker's DLL. This allows for the execution of arbitrary code that will be executed with the privileges of the target user, potentially resulting in a full compromise of the affected system.