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.