We gained an insight into the complexity of modern software engineering and the tangled web of connections between major IT companies when Microsoft announced details of a new security vulnerability that affects Exchange 2007, Exchange 2010, and SharePoint 2010.
The problem occurs in the WebReady component, which was first seen in Outlook Web App (OWA) in Exchange 2007 as a way for users to be able to view documents in common file formats such as Word through a browser window without having to fire up the underlying application. SharePoint’s problem occurs in the FAST indexing service, but we’ll leave that to one side for now.
Behind the scenes, Exchange’s WebReady component relies on a worker process called TransCodingService.exe, which runs on the Exchange Client Access Server (CAS) that services the user connection. TransCodingService.exe depends on a software library called “Oracle Outside In” that Microsoft licensed from Oracle to deliver the viewing capabilities and it is in this library that Oracle discovered a vulnerability that caused the problem to arise. I’m not quite sure why Microsoft felt it necessary to buy in the software license from Oracle, especially when Microsoft has a certain expertise in file formats that you wouldn’t automatically attribute to Oracle, but I’m sure that it was a case that buying a license was the most expedient course to gain the functionality.
For now, the solution is to disable the WebReady feature on CAS servers. 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. Remember that if you have an OWA policy that explicitly enables WebReady viewing and have assigned it to any mailboxes, you will have to disable WebReady in the policies to make sure that users don't gain access to the feature via policy. For example, this command disables WebReady viewing for mailboxes that are assigned the "Executive Users" mailbox policy:
Set-OWAMailboxPolicy identity "Executive Users" -WebReadyDocumentViewingOnPublicComputersEnabled:$False -WebReadyDocumentViewingOnPrivateComputersEnabled:$False
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.
Because of the potential knock-on effect on users, it’s really a business decision whether you should disable WebReady on external-facing CAS servers (definitely a good thing to do) or all CAS servers (absolutely the safest thing to do). Before making the call, it would be a good idea to discuss the problem with your company’s IT security team to ensure that all parties are on board with the eventual fix. Keep in mind that Microsoft hasn’t indicated if or when they will provide updated WebReady code that removes the vulnerability, probably because Oracle hasn’t yet notified them of a date for an updated software library.
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.
According to Microsoft, the problem doesn't afflict Exchange 2013 Preview because they haven’t yet provided WebReady functionality in this release. Exchange 2013 does use the FAST indexing service to replace the Exchange 2010 content-indexing service to keep track of mailbox database contents, including public folders for the first time (but only the modern public folders that have been moved to Exchange 2013 mailbox databases). Using a common indexing engine across multiple products makes eminent sense and I view it as a good thing to see Exchange and SharePoint use FAST.
In passing, I note that there’s been some reports from people using the Exchange 2013 Preview that they’ve observed the “noderunner” processes to use a lot of memory – or at least more than expected. These are the FAST indexing processes that perform tasks like content indexing, handling client queries, administration, and so on. At this stage it’s reasonable to expect that Microsoft has some work to do to tune Exchange 2013 before its final release, so I’m not too worried about reports about performance or memory usage. The same issues have surfaced in every beta test of Exchange since its original release. In any case, given that we’ve all become hooked on using queries to locate messages in ever-swelling mailboxes, isn’t it reasonable that the search processes should need a lot of memory to service these requests? Seems logical to me.
Follow Tony @12Knocksinna
Update August 14: Microsoft has fixed the WebReady bug in Exchange 2010 SP2 RU4 and Exchange 2007 SP3 RU8. Make sure that you read my post about the change in MFA processing implemented in RU4 before you deploy this update.
