(another) MS Outlook hole in embedded metafiles?

[Michael.Wojcik () MERANT COM (Michael Wojcik)]

Note: I'd been holding on to this query until I had time to investigate
further, but the @Stake Advisory released today about Outlook and CIL files
makes me even more suspicious that there's a potential exploit here, so I
thought I'd send this out now and perhaps get some feedback.

Since corporate short-sightedness is still forcing me to use MS Outlook for
email, I've tightened my Outlook settings down about as far as they can go -
customized security settings with everything set to "Prompt" or "Disable",
attachment security set to "High", all registry edit flags' auto-open bits
cleared (thanks to Wanderley Junior's RegFix).

However, one of the locals insists on sticking a "Microsoft Clip Gallery
Object" in her notes.  Besides being another 9KB of e-snot, this is in
effect an attachment that Outlook will automatically process *regardless of
security and edit flags settings*.  Near as I can tell, there's no way to
disable it.

(It's actually sort of a quasi-attachment, in terms of Outlook's processing.
It causes the attachment flag to appear in the folder list, but Outlook
ignores the File->Save Attachments... menu selection for the message.)

The Object - a (aesthetically unappealing) picture - is apparently a Windows
OLE object.  Right-clicking on it in the message provides various options,
including Edit (which fails, as I don't have the required control installed,
thank goodness) and Properties, which allows me to change the view to Icon.
Unfortunately, there doesn't appear to be a way to force the default view to
Icon, which would fix the problem.

I saved the message to an Outlook message file and ran strings against it.
(Saving it in any other format loses the picture.)  The source of the object
appears to be C:\Program Files\Microsoft Office\Clipart\Popular\amidea.wmf -
a Windows Metafile.

The issue is that in order to display the picture, Outlook has to invoke
something to process the metafile data.  I haven't looked closely at the
Windows Metafile format, but metafiles need to be parsed, which opens the
door to deliberately malformed files that exploit buffer overruns.  A quick
search of the Bugtraq archives didn't turn up anything on the subject, but I
don't think anyone wants to assume it's safe.  At the very least a DOS seems
likely.  (If Outlook will insist on processing any embedded metafile, then
even a well-formed, but extremely complex, metafile could potentially be a
CPU time or memory DOS.)

It's possible that the image itself is being transmitted in some more
innocuous form (raw bitmap, perhaps), but the presence of the "Edit
Microsoft Clip Gallery Object" option on the context menu suggests
otherwise.  And the presence of embedded strings that aren't part of the
message text suggest indirect exploits (as in the .CIL file bug - see
below).

In short, this is potentially a vulnerability on the order of the Outlook
Javascript bug posted to VULN-DEV not that long ago - an exploit that only
requires viewing, or previewing, a hostile message.  And while this is not
precisely the .CIL file (Clip Art Gallery) vulnerability posted on 8 March
2000 to BUGTRAQ by @Stake (written by dildog () l0pht com), it's also immune to
the fix for that vulnerability.  Adding a CIL type to Explorer (if it
doesn't already exist) and setting the Confirm Open flag doesn't prevent
Outlook from processing the image.  (Ditto for adding a WMF type.)

I'd be interested to hear if anyone with more knowledge of the Windows
Metafile format thinks it lends itself to exploitable parsing errors.

Michael Wojcik             michael.wojcik () merant com
MERANT International Inc.
Department of English, Miami University