
A year of Windows kernel font fuzzing #1: the results - ingve
https://googleprojectzero.blogspot.com/2016/06/a-year-of-windows-kernel-font-fuzzing-1_27.html
======
pierrec
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.

~~~
kevingadd
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.

~~~
pierrec
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...](https://bugs.chromium.org/p/project-
zero/issues/detail?id=369)

~~~
ryuuchin
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](https://github.com/khaledhosny/ots)

~~~
zeta0134
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?

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

[https://dev.opera.com/blog/300-million-users-and-move-to-
web...](https://dev.opera.com/blog/300-million-users-and-move-to-webkit/)

"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](https://news.ycombinator.com/item?id=5237967)

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

~~~
pcwalton
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...](https://technet.microsoft.com/en-
us/library/cc750820.aspx#XSLTsection124121120120)

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.

~~~
ayuvar
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...](https://www.symantec.com/security_response/vulnerability.jsp?bid=34012)

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.

------
chris_wot
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...](https://bugs.documentfoundation.org/show_bug.cgi?id=62764&redirected_from=fdo)

------
x0x0
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?

~~~
aab0
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...

~~~
MaulingMonkey
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).

~~~
pierrec
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.

~~~
aab0
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.

~~~
pierrec
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.

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

~~~
MaulingMonkey
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.

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

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

~~~
coldtea
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...

~~~
cm3
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.

