A year of Windows kernel font fuzzing #1: the results | Hacker News Reader

A year of Windows kernel font fuzzing #1: the results

googleprojectzero.blogspot.com

138 pointsingve38 comments

Being not entirely up-to-date on current browser security, what's the risk of a webpage just including a CSS:

    @font-face { src: url("/fonts/evil-font.ttf"); ... }

And making use of these? Do current browsers even use windows libraries for font handling?

Edit: reading further, the article actually mentions two browser exploits, the first of which links to a proof-of-concept which is just a font file. So yes, it seems that just including a carefully-crafted font (an OTF in this case) could take your shellcode directly to the kernel.

Native font rendering is used on Windows, yes, though in theory a browser could run some sort of sanitizer on TTFs. Not sure offhand whether they do, but it's reasonable.

Regarding the question of whether browsers sanitize the fonts, I'm looking at the chromium issue linked to what the article calls a "weaponized exploit", and even though it's marked as fixed (obviously), it's not clear whether they marked it as such because windows released a security update or because chrome did with sanitation. While the idea of monkey-patching kernel bugs through sanitation is kind of ugly, it would be also be ugly to rely on windows updates, considering that many people are furiously/incorrectly disabling them because of the ridiculous windows 10 update behavior...

https://bugs.chromium.org/p/project-zero/issues/detail?id=36...

It's marked fixed because Microsoft released a patch for it. However at the very least Chrome and Firefox have been doing font sanitization for quite some time now (several years+ I believe). I'm not sure for other browsers. Opera might since it's just a Chromium fork and OTS[1] is a part of the WTF (webkit tools framework).

[1] https://github.com/khaledhosny/ots

Wait, since when is Opera a Chromium fork? They've been around a lot longer than the Chrome project. Unless they had a radical change of heart recently that I haven't heard about yet?

Published on 12 February 2013: "300 Million Users and Move to WebKit"

https://dev.opera.com/blog/300-million-users-and-move-to-web...

"Opera sends 90 out the door"

"They were sacrificed for strategic choice to dump core technology, with Opera's proprietary engine Presto and JavaScript interpreter Carakan"

https://news.ycombinator.com/item?id=5237967

I think the issue of XP/Server 2003 systems that will never receive a patch are more important. What is fun is the MS15-077/MS15-078 fiasco where one ATMFD patch was released for Server 2003 and another about a week later was not. OTS has been used for a long time now by browsers BTW.

Both Firefox and Chrome use font sanitizers[1]. I'm not sure about others, Opera probably does since it's just a Chromium fork and OTS is part of the WTF (webkit tools framework). AFAIK its been used for quite some time now, several years+.

The license for OTS is permissive so I don't see why it couldn't also be used in Edge/IE although I've no idea if they do (or if they rolled their own even).

[1] https://github.com/khaledhosny/ots

And it seems that Flash and Adobe Reader don't use the sanitizers, according to the article?

Tangential, anybody knows how Apple handles fonts?

Reading commit messages from Chrome's support[1][2][3] for win32k system call disable mitigation (aka win32k lockdown) on Windows (specifically for PPAPI plugins) I think Flash, at least in Chrome, loads fonts from the browser. Which would mean it gets passed through OTS. I think all processes now share a common font cache on Chrome or at the very least they share code related to handling fonts.

Just looking at the fact that Flash still works with win32k lockdown enabled (meaning it can't use any GDI system calls) is probably enough evidence on its own (maybe). I don't know how other browsers handle font handling with Flash.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=523278

[2] https://bugs.chromium.org/p/chromium/issues/detail?id=523278...

[3] https://bugs.chromium.org/p/chromium/issues/detail?id=523278...

Firefox does include a font sanitizer https://support.mozilla.org/en-US/questions/913498

It seems they check it with ots: https://cs.chromium.org/chromium/src/third_party/ots/README?...

What is the main advantage of having font handling in the kernel?

The decision dates back to 1996, to improve performance by reducing context switches in Windows NT 4.0. See Microsoft's detailed rationale paper from that era: https://technet.microsoft.com/en-us/library/cc750820.aspx#XS...

The relevant ironic quote: "Due to the modular design of Windows NT moving Window Manager and GDI to kernel mode will make no difference to the security subsystem or to the overall security of the operating system."

This was, as these things often go, an expedient decision made in the '90s that wouldn't be fixed for nearly 20 years.

Pretty much all of GDI used to be in the kernel, the font stuff is one of the major parts still remaining, although the article says that Microsoft is moving it out as of Windows 10.

A few years ago there was a remote code execution exploit that had to do with decoding EMF/WMF images in the kernel: https://www.symantec.com/security_response/vulnerability.jsp...

I believe that one got at least partially fixed by moving some of the video code out of the kernel and into user-mode with Vista, but I don't recall exactly.

Even without fonts there are still user mode callbacks and other problems.

Compromising for speed and ignoring reliability and security concerns. I'd say it's human nature just like in many situations most people have a hard time being patient. Time and again the better but less fancy or less performant solution have been dismissed. Without the likes of i960 or BS-5000 (or lowRISC), safe code will invariably incur some slowdown like, say, bounds checks or GC overhead. Even with Rust we're trying to elide bounds checks, for good reason of course, so performance is important. But, the priorities are wrong because we tend to favor spending cycles on fancy aesthetics rather than harder to exploit code.

To give an absurd example: what good is a fancy looking/feeling ATM if every third transaction gets siphoned to another continent?

Back when this transition happened in NT4, it actually led to many crashes which weren't there in the microkernel'ish design of the feature in NT 3.51.

I'm hopeful we'll return to Microkernel systems where couple with a capability system the damage an attacker can cause will be substantially smaller.

Whatever the reasoning, it probably was justified in a similar manner as http.sys is justified (which is a ring 0 HTTP server Microsoft ships with IIS).

Don't think for a moment this can't BSOD your system. A LibreOffice font caused a BSOD on Windows 7 SP1, and whilst I sent memory dumps to Microsoft they eventually never got back to me.

As far as I'm aware, I guess this can still occur.

https://bugs.documentfoundation.org/show_bug.cgi?id=62764&re...

So google paid to find 16 vulnerabilities in Microsoft's TrueType font engine. One of which was actively being exploited and sold to governments / any thugs with $$$ by Hacking Team. Am I the only one who finds it stunning that Microsoft is too lazy to do their own fuzzing?

Or MS has fuzzed it but hasn't devoted as many computational resources as Google has. They say that fuzzing-produced bugs have come out regularly over the years, so clearly no one else had before applied as many resources as Google did...

Or used a different fuzzer with different mutators, or did blackbox non-coverage non-tracing fuzzing, or fuzzed the entire program instead of individual methods, or simply missed a program/driver/???, or ...

EDIT: RTFAing, Google even mentions using longer runtimes:

> As shown in the table, the crashes were reported in three iterations: the first one obviously contained the bulk of the issues, as the fuzzer was hitting a lot of different states and code paths right from the start. The second and third iterations were run for a longer time, in order to shake out any crashes which might have been masked by other, more frequently hitting bugchecks.

EDIT x2: Also, it looks like they moved it out of the Kernel in Windows 10, so that's good.

> It's also worth noting that while the elevation of privileges scenario is mitigated in Windows 10 by the architectural shift to performing font rasterization in a user-mode process with restricted privileges, an RCE in the context of that process is still a viable option (although much more limited than directly compromising the ring-0 security context).

Also RTFAing, the authors express their surprise at how easy some of the vulns/crashes were to find using very basic fuzzing. So while @x0x0 might be jumping to conclusions a bit harshly, saying that MS did little to no fuzzing on their font libraries is actually a reasonable guess.

That, however, contradicts their other assertion that past researchers have fuzzed the fonts and found many vulnerabilities. They can't both be easily true, so there must be something further going on.

Meh.

"it was trivial to discover with a dumb fuzzer, and it's surprising that such a bug could even survive until 2015, with so much work being supposedly put into the security of font processing."

(Emphasis mine.) I suppose they might be underplaying the complexity of the steps required to reproduce their finds, but it really doesn't look like it. Honestly I'm not that surprised. At times like this I'm reminded of the sheer amount of security holes out there in the wild and I just want to chuck my computer in the lake.

Turns out lakes are security thru obscurity. They do not provide as much security as previously thought. Consider an active volcano next time.

DBAN all the disks, smash all the chips, degauss the scrap and ship straight to your nearest neutron star. Proceed to direct said neutron star into the nearest black hole. Accelerate said black hole to at least five 9s of c, along whichever vector is least convenient.

The backup tapes? I'm sure the trash is fine.

Or MS has fuzzed it, it was terribly productive, and they fixed the bugs without confessing how they found them.

How many of those vulnerabilities would have been caught earlier in a safe language like Rust?

Is this a new meme on hacker news now?..

How long would it take until a Rust reimplementation would be as mature as the current ones?

This "just rewrite in Rust to have it be secure" is the new "just rewrite everything in assembly to have it be fast" that is popular with newbie programmers, CS freshmen etc, when they first learn about the various languages, but don't yet appreciate or understand the broader ecosystem implications...

I agree that lets-ASM has been wrong in most cases. However misguided in many cases it may be, in this context it's serving a more pressing problem than the lets-ASM mentality because there is a real security problem with most code that can be solved with different language+tooling and is only insecure because of historical popularity reasons like the rise of C in the 1980s.

https://github.com/google/font-rs

That doesn't answer the parent's point at all.

If anything it re-enforces it. From the repo introduction:

The current state of the code is quite rough. It's not known to compile with stable Rust 1.0 (the original version was written well before 1.0 stabilized), it doesn't handle composite glyphs, the code isn't organized with Cargo, and it's basically not ready for prime time.

It should build with 1.0 since a recent update, but your other points are valid. That said, it's a PoC and kinda like a MVP. Granted this is from a domain expert, so the time it took Ralph Levien to code this is substantially shorter than it would have taken a beginner in the field of font rendering. However, it's easy to see that something like font-rs can be incorporated into Firefox in the future even before Servo is complete. It's already happening with image decoders.

To answer the parent's questions, which I unfortunately forgot to: if we translate Harfbuzz and FreeType to Rust, it won't take that long. See Dropbox's recent blogpost about their translation of Brotli's C code to Rust.

I guess many wouldn't ever exist at all. But Rust wasn't around when the code was written of course.

Rust still isn't around, so to speak.

Reply on news.ycombinator.com