bugtraq - Re: OLE DB Provider for Oracle multiple DLL side loading vulnerabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <56BCB156.1030402@securify.nl>
Date: Thu, 11 Feb 2016 17:05:42 +0100
From: "Securify B.V." <lists@...urify.nl>
To: Stefan Kanthak <stefan.kanthak@...go.de>
Cc: bugtraq@...urityfocus.com
Subject: Re: OLE DB Provider for Oracle multiple DLL side loading
 vulnerabilities

On 11-02-16 14:14, Stefan Kanthak wrote:
> "Securify B.V." <lists@...urify.nl> wrote:
>> Microsoft released MS16-014 that fixes this vulnerability.
> Such vulnerabilities can be exploited without Office or OLE
> (see "Example 7" of <http://seclists.org/fulldisclosure/2013/Jun/123>):
>
> [snip]
>
> Instead of a VBScript you can of course use JScript too:
>      new ActiveXObject("MSDAORA")
> Both the VBScript and JScript can be wrapped into a *.WSF instead
> of a *.VBS or *.JS.
>
> A *.HTA or *.HTM (to be opened with Internet Explorer) which contains
> the following snippet can also be used:
>
>      <OBJECT CLASSID="CLSID:E8CC4CBE-FDFF-11D0-B865-00A0C9081C1D">
>      </OBJECT>

Hi Stefan,

Thank you for your insight and you are absolutely right. If I can force 
*any* application in loading the affected object, that application may 
be subject to DLL hijacking. Office is just an attack vector here.

The point is that a DOCX is somewhat trusted (if we ignore the whole 
macro thing). If I can trick someone to open a malicious VBS/JS/HTA it 
is basically game over.

In case of a DOCX I can put it on a network share. If a victim opens the 
DOCX from this share, Word will use the share as the current working 
directory. Thus I can put the hijacked DLL in the same share. It is even 
possible to hide the DLL using file attributes or if the attacker 
controls the share (Webdav, Samba) remove the DLL from the directory 
listing.

With regards to Internet Explorer, the current working directory is most 
of the times the user's Desktop, which makes it harder to exploit. You 
need something like the Safari Carpet Bomb or have the user save the DLL 
for you.

Best,

Yorick

>> On 16-12-15 19:27, Securify B.V. wrote:
>>> ------------------------------------------------------------------------
>>> OLE DB Provider for Oracle multiple DLL side loading vulnerabilities
>>> ------------------------------------------------------------------------
>>> Yorick Koster, August 2015
>>>
>>> ------------------------------------------------------------------------
>>> Abstract
>>> ------------------------------------------------------------------------
>>> Multiple DLL side loading vulnerabilities were found in the OLE DB
>>> Provider for Oracle. These issues can be exploited by loading various
>>> OLE components as an embedded OLE object. When instantiating the object
>>> Windows will try to load the DLLs oci.dll, and ociw32.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.