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 (11)
  1. Foolhardy says:

    >>A somewhat neglected feature that’s been in Windows since Windows 2000 is job objects…

    I really wish there was a better user interface to these features. The official UI methods that I know of are: a server resource management program (I forget the name), which I presume uses jobs, the “Run this program with restricted access” option of Run As makes a basic restricted token, the similar option of Process Explorer, and the Untrusted, Basic User and Restricted SAFER levels use, which use restricted tokens, with job objects to mitigate desktop attacks.

    Still, it’d be nice to have a command line scriptable or otherwise automated interface with fine grained control over groups and job limits built into the OS. I ended up creating my own command line app, ulimitnt (see post URL), to utilize restricted tokens, jobs and desktop objects effectively.

    It’s a shame too… restricted tokens are very powerful: it’s even possible to build an application rights (as a subset of the user’s rights) framework with some planning.

    [dcl] I agree – most of this is left over from an early sandboxing project, but one problem is that a lot of stuff breaks, and it’s a support call waiting to happen if you do use it on regular apps. You really need to build an app to run in an environment like this. Stay tuned – once you see the details, you’ll see the complexity.

    That said, I’ve been tossing around the idea of making a toolkit so that people could use all this more easily. No promises, but I’ve had thoughts much along the same lines as your comments.

  2. Russ Cooper says:

    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!



  3. Ryan Russell says:

    Hm, app proxy for file formats, huh?

    Is there a page somewhere that would tell one how to configure the jail mode, if one wanted to see what could be done from there, independent of MOICE?

    [dcl] It isn’t configurable, so it would be a very short page. There is one thing you could do to further tweak it on Vista, which would be to add some deny all firewall rules for the converters. I would have liked to have that in there, but we wanted to get it out for people to use, and you could do that with a VB script if you liked.

    You wouldn’t want to tighten the screws any further – they’re already screwed down as tight as they can get without breaking things – we went overboard, then backed off just enough for things to run, and had to fix a couple of things in the apps for it to work.

    I will be documenting everything we’ve done, and might even wrap this into a library you could use for your own apps, though don’t hold your breath – I’m really busy. It will probably eventually happen, but I can’t commit to even a vague schedule.

  4. Justin Polazzo says:

    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?


    [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.

  5. Justin Polazzo says:

    sorry, the 2003 should have been removed from that question….

    I have a lot of friends at colleges that could use this, but also still have office 2000 running.

    would this work for them as well?


    [dcl] Office 2000, or Office XP? Support for the converter pack is:


    • Supported Operating Systems: Windows 2000 Service Pack 4; Windows Server 2003; Windows XP Service Pack 1
    • Recommended Microsoft Office programs:
      • Microsoft Word 2000 with Service Pack 3, Microsoft Excel 2000 with Service Pack 3, and Microsoft PowerPoint 2000 with Service Pack 3
      • Microsoft Word 2002 with Service Pack 3, Microsoft Excel 2002 with Service Pack 3, and Microsoft PowerPoint 2002 with Service Pack 3
      • Microsoft Office Word 2003 with at least Service Pack 1, Microsoft Office Excel 2003 with at least Service Pack 1, and Microsoft Office PowerPoint 2003 with at least Service Pack 1
      • Microsoft Office Word Viewer 2003
      • Microsoft Office Excel Viewer 2003
      • Microsoft Office PowerPoint Viewer 2003

    I’m not 100% sure what MOICE supports in terms of the full deal with file blocking and so on – that may be only Office 2003, but I can check on Monday. However, it can be used as a command-line tool to convert files to the new format, and they’ll do so in a protected manner. You can then open them with anything the converter pack supports (above). As far as the sandbox goes, I know it is tested on XP and up, not as sure about Windows 2000, and Win9x doesn’t support what it needs at all – no security on Win9x.


  6. alexeck says:

    Very interesting post. One question: How will one deal with current O27 files? You’re not going to “downconvert” and then upconvert those, are you? You’re just upconverting the older files?

    [dcl] exactly

    in other words, this doesn’t do anything to protect user’s from a Metro file which is exploited, right?

    [dcl] – right – this wouldn’t protect from a native Office 2007 file that is exploitable. It wouldn’t convert, and in the second place, if the converter itself could be made to run completely arbitrary code, it could emit any file it likes in the new format. If that file were an exploitable 2007 file, then you’d have an exploit. This is exactly why I said customers would be _safer_ – it’s still possible something could get through, but a lot of things will get blocked – there are whole classes of attacks that can’t make the transition.

  7. says:

    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

  8. Nathanael Jones says:

    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.

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

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

  11. Nu. Totusi, Office 2003 SP3 blocheaza o serie de formate de documente (foarte putin folosite in Microsoft

Comments are closed.

Skip to main content