Microsoft Office – OLE Packager allows code execution in all Office versions

http://seclists.org/fulldisclosure/2015/Jul/11

by tomtoise • 11 years ago

96 81 11 years ago

seclists.org

orionblastar7• 11 years ago

But the old versions of Office won't get patched only 2007 and above, right?

All the more reason to use OpenOffice.Org or LibreOffice.

therobot24• 11 years ago

Apple stopped patching Leopard (released in 2007) by 2011 and stopped supporting IOS 5 (released in 2011) just this year. Google is just starting to ditch support for Ice Cream Sandwich (released in 2011).

Why should Microsoft continue to support office below 2007?

toyg• 11 years ago

"From great power comes great responsibility."

- Benjamin "Ben" Parker, 1962

orionblastar7• 11 years ago

Some companies cannot afford to upgrade their hardware to run the latest versions.

They are stuck on older Windows versions that cannot run the latest Office versions.

I noticed a lot of companies still stick with XP. I watched the Terminator Genisys movie and had a display in the hallway with a pop-up that said XP support has ended. A lot of Movie Theaters use XP still. The US Navy still uses XP and an old version of Office.

cwyers• 11 years ago

Does LibreOffice give security patches for eight-year-old versions of LibreOffice?

nothrabannosir• 11 years ago

No, but I can.

I say this as an unapologetic user of all software closed source, Windows, Office, et al. I send files in .docx without asking if my peers even have Windows. I use Google Maps and closed source everything everywhere always.

But, even I cannot deny: if this were open source, many of the points leading up to this bug could be addressed without any help from the vendor.

davidgerard4• 11 years ago

Yes, a whole new version free ;-p

andzt• 11 years ago

All pre-2007 versions have been end of life/support for a while now. So yes.

orf• 11 years ago

If this is true then it's a huge mess:

- They used a static list of file extensions to blacklist

- This hasn't been kept up to date, powershell scripts are automatically executed

- There is no way to disable it

- Embedded files are executed within a trusted directory

I'm guessing Microsoft has to tread very lightly when messing with OLE, I bet a lot of legacy software from large Microsoft customers uses it.

EvanAnderson2• 11 years ago

I didn't see anything in that post to give me the feeling that code is being executed automatically. While I would concede that requiring the user to click on something inside the "payload" document isn't a high bar to achieve it is different than automatic code execution upon opening the document.

gossitd3• 11 years ago

It needs user interaction. POC Samples here: http://owned.lab6.com/~gossi/research/public/packager/ (made by me, safe to try).

UnoriginalGuy2• 11 years ago

This hasn't been kept up to date, powershell scripts are automatically executed

Powershell won't execute AT ALL by default. You have to enable execution. And it certainly won't execute automatically, the user has to click to run.

r00fus• 11 years ago

Legacy software and installations should be no excuse to be bug compatible to this level for recent versions and patches.

tdicola• 11 years ago

I've love to know a scenario where OLE is actually used today. It might have made sense in the early 90's pre-Internet & HTML computer world but really has no use today and is just a massive security hole. Seems like it should have just been completely removed (see also Vista's desktop gadgets, which were actually removed and disabled after realizing they were a huge security issue too).

EvanAnderson2• 11 years ago

I don't know how much it shares w/ OLE compound documents, but OLE for Process Control (OPC, now retroactively renamed to "Open Platform Communications") is very common in multi-vendor SCADA environments.

testrun• 11 years ago

It has a common ancestry, but OPC moved on. They are now using OPC-UA. And the usage is totally different. In OPC you do not imbed one app in another, it is a standardised protocol to get data from DCS/SCADA. But they did use DCOM up until OPC V 3.

stephengillie3• 11 years ago

The basic idea was great - copy some cells out of Excel and paste them into Word. You can put your sales statistics into your end-of-quarter report.

Then they added linking, so when the spreadsheet was updated, your report would update too. So you could make the report early, let Accounting update the spreadsheet, then just let the report auto-update.

I'm pretty sure Outlook uses the Word rendering engine. And dragging documents into Outlook is one of the ways to attach/embed a file into the email. So I'm pretty sure this still leverages that code.

I'm actually guessing this is almost everywhere. Maybe it didn't get put into Vista (where a number of security enhancements like the 2-level model aka UAC elevation got made) but it's still all over Office. I wonder if IE is impacted.

so0k• 11 years ago

or link to the latest covers to make sure they are always up to date. no longer need to worry about those memos, wouldn't that be great?

julian_t• 11 years ago

Then they added linking

And that's great, until someone inserts a couple of rows into the range you've linked. Or moves the file. Or any one of another hundred things could happen to upset the OLE Gods.

Do not go anywhere near OLE linking... that way lies madness.

brudgers• 11 years ago

In the past I've used OLE regularly for Excel spreadsheets in AutoCAD drawings. Nothing else came close in terms of ease and reliability or standardization. OLE is a powerful technology and the complaint tastes a bit like "no one should use JavaScript because of XSS" on the palette. I mean just think what malicious input can do If passed to python in the shell.

WalterGR2• 11 years ago

    I've love to know a scenario where OLE is actually used today.

Does it play no part in all of the [Clojure/Python/other langauge]-in-Excel posts that tend to get a decent number of upvotes here?

Maybe I'm mistaken about that - but it could have powered the kind of uber-notebook-in-Emacs packages that seem to be gaining popularity lately - twenty years ago.

clebio• 11 years ago

Specific to the Microsoft Office suite, or in general?

I spent some time trying to automation Powerpoint and Excel creation via Python, which is based vaguely on the capability: http://clebio.github.io/pythonOfficePresentation.html

Unrelated to Microsoft Office, I wrote a Perl utility that would run QXDM (telecom call testing software) via OLE in order to automate the initiation and answering of cellphone calls (think drive-testing or load-testing a cellular network). It was quite useful. Qualcomm, who licenses QXDM, had a fairly good reference document for the OLE interface to the program.

mxmauro2• 11 years ago

Why you consider it is a huge security hole? Just because of the OLE Packager bug?

COM/DCOM, where OLE rests, can be very secure if they are properly used.

By the way, OLE is used widely mainly in Microsoft products.

x0n2• 11 years ago

I read the post and I don't see any "bugs" pointed out per-se.

pjc50• 11 years ago

OLE the technology is rather fundamental to custom controls and a whole load of other things. You could probably remove all OLE embedding from Word documents and not break too many use cases, but in other applications it may be more important.

nickpsecurity• 11 years ago

Might be misremembering, but I think there's a variant of it used heavily in industrial automation (eg factories). It was a standard that you had to buy for a significant sum of money. The friend in embedded design that told me didn't like it but many groups used it. Can't remember what it's called...

Past that, it's probably just there to make legacy software work like so many other problem-causing, Windows features. :)

UnoriginalGuy2• 11 years ago

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.

That's a poor example. Powershell scripts won't execute by default at all, and a lot of enterprise customers will only execute scripts signed by the internal CA.

Off the top of my head I cannot think of too many new ways of running executable code. Microsoft has only been removing them, not adding news ones. Powershell is one of the few new ones and is designed from the ground up expressly not to allow this type of thing.

scott_karana• 11 years ago

Originally, Powershell did NOT have execution policy. And even in versions that do, it's also at the mercy of the invoking process, as I recall.

Which is why he specifically said "powershell embeds without any security warning", I suspect. :|

https://blog.netspi.com/15-ways-to-bypass-the-powershell-exe...

hug• 11 years ago

On an OS that is still under Microsoft support, all of those "bypasses" require:

A) An argument to powershell.exe which Office will not supply when executing the ps1 file or

B) Interacting with the powershell window after it's opened (which you can't do without already having some sort of code execution) or

C) The execution policy being set to something that allows unsigned code.

A and B are impossible, and C can be locked down with group policy to the point that local administrator rights can't bypass.

Executing a ps1 with the appropriate parameters after executing something else may be possible, but also redundant.

x0n2• 11 years ago

PowerShell execution policy is not a security layer/boundary. It's just a simple mechanism to stop people unintentionally shooting themselves in the foot; it won't stop other people intentionally shooting you in the foot.

useerup• 11 years ago

Originally, Powershell did NOT have execution policy.

Yes it did. It always had default execution policy to not allow scripts to execute. Not sure how it was set in the Monad days before PowerShell 1.0 was released, but for as long as it has been called PowerShell, execution policy has been part of it.

On top of that, the .ps1 file extension is associated with notepad - not the PowerShell interpreter. When you "invoke" a ps1 file (like double-clicking it or have some program like outlook take default action), Windows will open notepad unless you explicitly associates .ps1 with another program.

stephengillie3• 11 years ago

It depends on the system. I've had installs where I had to enable execution, remote execution, and unsigned execution. Other systems run network-based scripts without any complaint.

makomk• 11 years ago

Wow, this takes me back. I remember getting in trouble at school as a kid for using this to attach executable code to e-mails and bypass all the warnings and filters. That must've been, ooh, about a decade and a half ago now. I'm shocked it still works in our modern security-aware age.

RKearney3• 11 years ago

For those of you worried about this, I tested it at work and it was blocked by our Software Restriction Policy that I put in place just a few weeks ago.

The execution of %TEMP%\PAYLOAD.EXE was blocked.

I highly urge everyone to deploy a strong Software Restriction Policy in whitelist mode. It catches everything we've thrown at it so far.

stephengillie3• 11 years ago

I didn't know this was available until now. Another tool for the toolbox!

huhtenberg• 11 years ago

There's also AppLocker in W7+ :

https://msdn.microsoft.com/en-us/library/dd548340%28v=ws.10%...

and I would guess it's very closely related to SRP -

https://technet.microsoft.com/en-us/library/ee424371%28v=ws....

gossitd3• 11 years ago

hi, I wrote the advisory. Here's some POC I just published here: http://owned.lab6.com/~gossi/research/public/packager/

The SalesOrder.rtf file is safe to try at work. All it does is lock your workstation. It should work behind Software Restriction Policy and Microsoft AppLocker (and Citrix Application thingy).

RKearney3• 11 years ago

The RTF opened a zip folder with a .js file in it.

Attempting to open it with the default Windows Based Script Host results in a dialog box from Software Restriction Policy stating that execution was blocked.

reiichiroh• 11 years ago

Would someone renaming the payload to a filename of something that's whitelisted defeat the whitelist?

RKearney3• 11 years ago

It depends how the whitelisting is done. We just have C:\Windows, C:\Program Files, and C:\Program Files (x86) whitelisted.

This means that any exe (or scr, bat, vbs, etc), ran from any other location, will not run at all.

This of course caused problems with GoToMeeting and Google Chrome (and other programs that install to AppData), but the fix was to track down the msi installer for corporate deployments to have it install to Program Files.

girvo• 11 years ago

This is how I used to get around Novell NetWare in high-school to run compilers and learn programming. Funny to see it still exists.

cesarb• 11 years ago

Does the same exploit work on Wine? It has its own implementation of packager.dll, which doesn't seem to have any blacklist. What happens if for instance Wine is being used to run Microsoft Office?

drsim• 11 years ago

Ha, I didn't know this still existed. I 'hacked' our school PCs running Windows 3.11 using this technique.

The sysadmin locked down every possible way to run executables apart from those he exposed in Program Manager. Of course, everyone had Word. Simply embedding an OLE object let me run any exe.

callesgg• 11 years ago

Someone still needs to click the thing to execute it. Clicking any executable in windows will launch it. I really can't see the difference that makes this so bad.

User clicks executable in office it launches....

User clicks executable in explorer(or other software) it launches....

nikbackm• 11 years ago

So there is no way to get the executable to auto-execute when you open the document that embeds it?

Microsoft Office – OLE Packager allows code execution in all Office versions

Related Stories