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-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 3 Jul 2015 08:45:00 +0100
From: Kevin Beaumont <>
Subject: Re: [FD] Microsoft Office - OLE Packager allows code execution in
 all Office versions,
 with macros disabled and high security templates applied

All - it is probably bad form to respond to my own post, but I've seen some
folk dismiss this out of hand on social media so I wanted to provide two
VERY QUICK proof of concept examples.  These were just put together in 10

There's an RTF and .docx version.

You should be able to email these to colleagues.  The "Sales Invoice" file
is a .js file executed in Windows Scripting Host, which causes your PC to
lock (as in, Ctrl+Alt+Delete lock - nothing malicious).  It should work
even if you have application whitelisting setup, by using Rundll32.

Both examples have 0 out of 53 engine detection on Virustotal, and pass
undetected through Cuckoo and Palo-Alto sandboxing, and endpoint security
tools I've tried.  The RTF should pass through most of the leading cloud
mail gateways.

On 2 July 2015 at 10:31, Kevin Beaumont <> wrote:

> All,
> 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
> OS.
> 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.
> --Kevin

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

Powered by blists - more mailing lists