Do any Exchange hardening guidelines recommend disabling OWA Webready? Should they?

Question

For the fourth time in over a year, Exchange OWA has put our internal network at risk due to a remote code execution flaw that exists on the server runtime. This risk is compounded by the fact Microsoft won't support OWA in the DMZ.

The issue has to do with the CAS server's (also known as Outlook Web App / OWA) "Outside in" DLLs. These are the files that parse PDFs and Word email attachments into HTML documents for HTML based preview. I would compare this exploit to a server-side buffer overflow triggered by simply sending an email to an unsuspecting recipient.

According to this Microsoft's patch history, the webready sub-component isn't fairing too well security-wise with all these patches in a two year period:

• MS13-061 (Note: Update recalled 8/14/2013 due to a bug)
• MS13-012
• MS12-080
• MS12-058
• MS16-079

Note these files are developed by Sun/Oracle and the alerts were public long before Microsoft made these public. This list may not be all inclusive, therefore a greater liability is implied.

Question

• Is there any deployment guidance of Exchange Server that recommends disabling Webready as a part of the security guidance?

• When did the security guidance (above, if it exists) get updated with the most recent advice?

The reason I'm asking is because Exchange is no longer supported in a DMZ or front-end backend configuration. This means that any breach of OWA might breach my internal network. (localservice mitigations aside)

The second reason I'm asking is so I can identify the most forward thinking, or most security conscious methodology that pertains to Exchange. If such a thought-leader exists, I want to subscribe to their blog, purchase their consulting, etc. Basically I want to be ahead of the curve and close whatever other security gaps may exist. I want to know what other components should I disable.

Answer 1

Makerofthings7,

I'm not saying this is a definitive source for you, but it's the best I can find "straight from the horse's mouth":

WebReady security vulnerability reveals complexity of modern software engineering

In that article by Tony Redmond, he states a few interesting things:

Microsoft recommends disabling the feature on all CAS servers, an approach that fixes the problem at the expense of removing some user functionality. You might consider such an approach to be a tad extreme, but a potential attacker might exploit the now-discovered weakness by encouraging a user to view an infected document (probably sent as a message attachment) with OWA after connecting to an internally-facing CAS

Now, whether you take that to mean "Microsoft temporarily recommends..." or whether Tony believes MS' approach is to disable it as it is simply a luxury item and security is more important...you'll have to make that call. As he states a short bit later:

As in all instances to do with security, you have to balance the potential risk of penetration and exploitation against the effect of applying a fix that removes user functionality. Of course, it’s entirely possible that no one cares about WebReady because it’s never used and so no one will miss it if you remove the feature from all servers.

One thing I did find interesting in the article (I know it doesn't quite help):

Users of Exchange Online in Office 365 don’t need to worry about the problem as Exchange Online uses the online versions of Microsoft’s Office applications to view common file formats.

So, take it for what it is...one man's blog article (albeit with some merit) discussing the issue and possibly paraphrasing Microsoft's unofficial stance.

Answer 2

Microsoft appears to be addressing this with the focus on Office Server, where word documents are previewed (and edited in some cases) on a separate server that resides in the DMZ.

Exchange 2013, and Lync 2013 (Skype for Business) both have some connection to the Office Web Server, but the Preferred Architecture for Exchange 2016 expects a deeper commitment to this format, and suggests an expanded deployment (Web Farm on a load balancer).

The justification was never specified, but in terms of this Sun exploit history, I'm happy the product is evolving this way.