New File Converter Coming Soon

You might have recently heard something about the new "Microsoft Office Isolated Conversion Environment", a tool we are providing to help protect Office 2003 users from malicious content in Office files. You might be asking yourself what it is, and why we need such a long name?

I really don't know the second question – marketing people and PMs put names on things, I just write code and try to help others write secure code. I do know a lot about the first question, and I have a series of blog entries planned to talk about how it works in some detail.

MOICE takes advantage of an effect we noticed while working on Office 2007 – when we get MSRC cases in, we have to check to see whether it affects each version, including new code. One of the things we noticed is that when we converted an exploit document to the new Office 2007 'Metro' format, it would either fail the conversion, emit a non-exploitable file, or the converter itself would crash. The possibility exists that something could make it all the way through, but we haven't seen any of those yet.

Thus, if we could pre-process documents coming from untrusted sources from the older format to the new format, and then get an older version of Office to use its converter to read in the new file format, the customer is going to end up safer. The way that this works is to associate the old document format extensions with MOICE, which will then upconvert the file to the new format, and hand it off to the real registered app to read in the file that's in the new format.

The reason this process ends up stripping out exploits is that the older formats would do things like write offsets directly into the file, and in some cases would write pointer values right into the file. It seemed like a good idea back in 1995 or so, but isn't something we want to do now. Because the new file format is meant to eliminate security problems and has a goal of simplicity (which is a great way to help make things more secure), that information often just doesn't make it across the conversion process. It's also true that the converter itself is composed of the same code used to process the older formats by Office 2007, and that code has the benefit of improvements we've made in Prefast (known in Office as OACR, for Office Automated Code Review), a huge amount of fuzzing, and many other improvements – all in all, the new code is going to be safer.

In order to get all this, you'll need to download and install MOICE when it becomes available, and you'll need to set a policy that opts you into using it. There are some downsides – converting a file twice before you can open it adds a performance penalty. Whether it's something you'll notice depends on the size of the files – if you use it to pre-process resume's, you may not notice, but larger documents could take a noticeable amount of time. We're also stripping out things like macros and VBA projects – sure, it's a big app-compat hit, but this is a security feature.

A big question for many of you, and the part I find most interesting, is the isolated converter environment. When we looked at the threats to this package, the most obvious is that the converter itself could have a fault that would result in running arbitrary code. As I've said recently, "Crashes are baaad, mmm'k", and we did see some crashes, and while the code is better, it isn't perfect or unbreakable. Some crashes are exploitable, and you're using this to process input you explicitly don't trust. Sounds scary to me.

What we did is used a set of technologies I've been working with for a few years, and we've shipped in a couple of other places. The first element is restricted tokens. A restricted token can be used to strip privileges and groups from an existing process token, and I've written about that in a couple of places, going back to around 1999-2000, as well as both editions of Writing Secure Code. I've learned a lot more about the ins and outs of restricted tokens since then, and it's possible to create a process with a restricted token that can't even open objects you own – has to do with some interesting uses of the SidsToRestrict argument to CreateRestrictedToken, and I'll be going into some detail on that soon.

Now that you have a restricted process, the main task is to keep that process from being able to hook into a non-restricted process, or spawn other processes. A somewhat neglected feature that's been in Windows since Windows 2000 is job objects – it's our version of how ulimits work on UNIX, and in some ways, it is a lot more powerful (and it's missing a couple things that ulimits have, too). With a job object, I can prevent a process contained inside a job object from creating more processes, and better yet, I can block a whole lot of desktop attacks – things like access to the global atom table.

The last part of the puzzle is the fact that the desktop is supposed to be a security boundary – any two apps running on the same desktop have a lot of opportunities to do things to one another, which is why we've done things like moving the console user off session 0 on Vista. Thus, if you put the process on another desktop, it has a limited ability to interfere with the original desktop. There's some interesting wrinkles to this part, but we've come up with some clever tricks to make it really work. Again, I'll go into some detail on this, too – I don't care for security by obscurity, and we're sure the bad guys are going to be picking this apart. What we'd like is for you to be able to use these same techniques to protect your customers.

What it boils down to is that even if you do get arbitrary code running in the converter, good luck getting it to do anything very useful. The operating system doesn't allow me to prevent you from opening a socket, but in terms of the local system, there isn't a lot you can do. I don't know of any way to break out, and some really sharp people here haven't managed to break out of the isolated environment, either. It probably isn't perfect, but it is difficult, and does raise the bar. An exploit that wasn't targeted directly at that sort of environment would be very unlikely to work correctly – one aspect of the isolated environment that cuts both ways is that you really have to build things to fit into it – a lot of normal apps won't work right.

At any rate, we'll be releasing MOICE in the near future, and once we do, I'll write a series of blogs about the technology behind the isolated environment. I'm also looking forward to feedback and questions about how it all works.

Comments

• Anonymous
  May 08, 2007
  The comment has been removed

• Anonymous
  May 10, 2007
  About time you got around to writing this David!! I can't wait to plug it into email gateways to replace MIME decoders with something better than magic byte detection capabilities! Please find a way for us to put this into a managed sink on Exchange! Cheers, Russ

• Anonymous
  May 11, 2007
  The comment has been removed

• Anonymous
  May 11, 2007
  What about people who do not run office 2007? Are you saying the 2003/2000 versions of office will still be able to read these converted-but-still-associated-with-older-version docs? -JP [dcl] That's the point - the converter pack allows downlevel versions of Office to read the new file format. So the file starts out in what was originally the native format for Office 2003, gets converted to the new format (and likely sanitized in the process), and you can then use the converter to allow Office 2003 to read it in.

• Anonymous
  May 11, 2007
  The comment has been removed

• Anonymous
  May 12, 2007
  The comment has been removed

• Anonymous
  May 15, 2007
  Bei der Entwicklung von Office 2007 ist den Entwicklern aufgefallen, dass in alten Office-Dokumenten enthaltener Schadcode verloren geht, wenn diese in das neue Format konvertiert werden. Genaugenommen passiert dies nicht immer aber die Wahrscheinlichkei

• Anonymous
  May 21, 2007
  Will this help with word 2.0 files in an way? We've still got thousands of Word 2.0 files, and newer versions of Word don't open them correctly. Word 2.0 won't run on newer computers, so we're going to be stuck when our last pentium 3 dies. [dcl] I don't know - it's basically the same code as Office 2007 would use to convert the files, so it would do the same job. If you've got lots of files, my assumption would be that most (all?) of them aren't malicious, and MOICE may be overkill. I believe Word 2 will run on a recent system - saw one of our devs run it on his Win2k3 system one day. You can also certainly install all this into a virtual PC running whatever combination of downlevel OS and Office you like. You don't need actual hardware. Given the security implications of the older parsing code, it isn't a great idea to expect us to support older formats forever. Taking into account the engineering cost of bringing that code up to current standards and the decreasing user base, something has to give. What might be a good idea for you would be to use whatever version of Office you feel has good fidelity (though we do strive to make this work really well - I'll accept your word in terms of how it works for you), and upconvert the files to something newer - Word 2 was great 15 years ago... Hope this helps - and this is all just IMHO, and not an official statement on behalf of Office.

• Anonymous
  October 01, 2007
  Как всегда: начинаешь копать одно, а выясняешь для себя много нового совсем из другой оперы. Сегодня...

• Anonymous
  October 21, 2007
  Как всегда: начинаешь копать одно, а выясняешь для себя много нового совсем из другой оперы. Сегодня...

• Anonymous
  January 05, 2008
  Nu. Totusi, Office 2003 SP3 blocheaza o serie de formate de documente (foarte putin folosite in Microsoft