How exactly does Windows font rendering work?

An interesting (and fortunately patched) vulnerability in Windows XP through 7:

http://technet.microsoft.com/en-us/security/bulletin/ms11-087

Note that this is a bug in the handling of Truetype fonts. It is also a kernel vulnerability. If successful against an unpatched system, it will bypass pretty much any security measure, and execute its payload with full admin privileges.

I'm a bit confused by this. Is there in fact a kernel driver involved in font rendering on Windows?

If so, why? As far as I know, all font rendering on e.g. X11 is done in userspace, and as we all know, X11 is not a shining example of secure design. Is this a matter of design differences between the Windows display system and the X server? A way of using hardware acceleration to help with font rendering? Or could X contain similarly nasty kernel-level surprises in its DRI drivers?

 

Yes, it's in the kernel. There is a truetype virtual machine to handle it. JIT'd code in the kernel designed to parse fonts? What could possibly go wrong?

 

Umm. Why? What possible advantage could there be to handling font rendering in kernel space?

 

Because font rendering is very complicated, possibly performance critical. Cleartype, alaising, and subpixel rendering/ scaling come to mind. Not sure.

The disadvantage of it being in the kernel is that it adds attack surface, it's complicated and accessible. Worse is that it's JIT'd and not subject to various security mitigation techniques.

 

Thanks, I figured it might be for performance reasons. Font rendering performance on Linux is indeed much worse than on Windows in my experience (though that may have more to do with GTK2/Pango than FreeType, not sure).

 

A font rendering bug was just fixed in Mozilla's Firefox.