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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 Jul 2015 10:31:36 +0100
From: Kevin Beaumont <>
Subject: [FD] Microsoft Office - OLE Packager allows code execution in all
 Office versions, with macros disabled and high security templates applied


OLE Packager is a feature introduced in Windows 3.1, which ran "up to"
Windows XP:

It is still present in every version of Microsoft Office, on every Windows

It allows you to embed any file into Office documents.  It is also very
dangerous and there is no way to disable it.

To test, open Word 2010/2013 and select Insert -> Object -> Create from
File, and drop an executable into the document.  Double clicking the
executable then spawns the executable.  You can also right click the file
name, to change the name and use a custom icon.  You can use the Draw
functions to draw a white box over the file extension.

This isn't new (although I think most people aren't aware this function is
still active).

There's all sorts of problems, though:

- You can bypass many mail gateways and antivirus products by simply saving
the document as an .RTF file - these also support OLE Packager objects.
Most products I've tested fail to scan for Packager objects inside RTF
files, which are in turn then opened in Word by default.

- A dll file called packager.dll is used to determine if the file extension
can execute code via a static list, and displays a warning for the user to
click through.  There is no way to disable the Packager functionality, so
every Enterprise/Gov/Org/user has this functionality enabled right now.

- The DLL file hasn't been kept up to date.  For example, you can use .PS1
(PowerShell) embeds without any security warning.  There's a lot of file
types now you can execute code with without warning, basically.

- You can also embed executable code within ZIP files, to completely bypass
the warning.

- The files are executed from your %appdata% folder, which is trusted for
things such as Windows Scripting Host.  So for example, you can use
malicious .js files to execute full code, wrapped in a ZIP, with absolutely
no warning to the user nor ability to disable the functionality, even with
Group Policy/high security Office templates etc.

I've tried this technique with most of the large cloud based email
filtering companies and it just sails past them.  I've also tried two
anti-exploit products (Malwarebytes Anti-Exploit and a company I won't name
due to NDA) and it doesn't trigger their protection.  No antivirus product
detected anything suspect during testing.

I notified Microsoft of my research back in March, but from the dialogue
I've had it's a supported feature dating back to the early 90s.  It also
appears to be supported going forward.  I think it blows apart security
models and basically provides an easy way to detonate code on PCs far
behind firewalls - my belief is organisations should be able to disable
this feature, and it should probably be disabled by default in future
Office versions.

As a mitigation, you can install Microsoft EMET and manually add
packager.dll to ASR.


Sent through the Full Disclosure mailing list
Web Archives & RSS:

Powered by blists - more mailing lists