

Results of recent PostScript CharString security research - acdha
http://j00ru.vexillium.org/?p=2520
Presentation slides: http:&#x2F;&#x2F;j00ru.vexillium.org&#x2F;dump&#x2F;recon2015.pdf
======
WallWextra
Does anybody know the precise (more precise than given in the slides) reason
Windows had to put a font renderer in the kernel? That's absolutely insane.

EDIT: holy jeez, this isn't even the whole thing. MS has their own first-party
ttf renderer in the kernel too, what the heck?

~~~
derefr
"In the kernel" is a bit of a misnomer in Windows. The graphics subsystem is
not in the NT kernel (which is a pretty-minimal microkernel), though it is
within the same Win32 process as the one containing NT kernel services.

In other words: "within the kernel" from a userland perspective; in a separate
security domain from NT's own perspective.

~~~
WallWextra
Does it execute in ring 0? I don't really understand how Windows works.

~~~
yuhong
Yes, as do the rest of win32k.

------
taspeotis
Great work. From looking at the PDF [1], it seems that this was done with
something like IDA Pro rather than from sources. I imagine work like this
would be a good candidate for the Microsoft Shared Source Initiative [2].

[1]
[http://j00ru.vexillium.org/dump/recon2015.pdf](http://j00ru.vexillium.org/dump/recon2015.pdf)

[2] [https://www.microsoft.com/en-
us/sharedsource/](https://www.microsoft.com/en-us/sharedsource/)

~~~
yuhong
Not even the PDB symbols are available for ATMFD, probably because it is third
party code originally included into Win2000.

------
userbinator
The biggest attack vector I see here is embedded fonts; perhaps allowing
browsers to download and use embedded fonts should be restricted to trusted
sites too, since some font formats _do_ contain an embedded Turing-complete
language. It gives a whole new meaning to the term "web-safe fonts"...

~~~
taejo
Turing-completeness isn't a problem _per se_ (lots of people get this wrong)
because no attacker is trying to _compute_ something: they want to run some
shellcode, or redirect an HTTP request, or display something on screen, or
something like that, _none_ of which a Turing machine can do.

The worst a Turing machine can do is run forever, which is easily prevented by
limiting the number of steps it can ran.

~~~
throwaway2048
this really misses the point/problem entirely, the problem with parsing a
turing complete format is that verifying data encoded with it in the general
case (as valid/non malicious/useful) is equivilent to the halting problem.

They are dangerous to parse not because they can potentially run forever, but
because due to their expressiveness, it is very easy to arbitraily trigger
bugs, aided by the massive nessisary complexity of most parsers.

Those two things together make avoiding logic errors invoked by malicious
data, leading to exploitability essentially impossible to prevent.

Another factor is it is impossible to formally verify something that executes
turing complete code.

~~~
taejo
Would a primitive recursive language be less dangerous? Well, it depends on
the language.

> They are dangerous to parse not because they can potentially run forever,
> but because due to their expressiveness, it is very easy to arbitraily
> trigger bugs, aided by the massive nessisary complexity of most parsers. >
> Those two things together make avoiding logic errors invoked by malicious
> data, leading to exploitability essentially impossible to prevent.

Actually, the _parsers_ for these languages are not too complex -- the problem
is that they're written in a language ill-suited to writing parsers. The
interpreters _are_ complex, but all the exploitability is very easily avoided:
by writing the interpreter in a memory-safe language.

This problem might be bug-prone, but a bug in a font interpreter should lead
to whacky looking fonts, and never to remote code execution. The fact that it
routinely does just shows we're using the wrong tools for the job.

~~~
throwaway2048
there are more classes of exploits than simply memory management errors. For
instance look at the laundry list of issues surrounding verification of x.509
certificates. Deciding a forged certificate is valid is catastrophic, and
invokes no sort of memory related exploit at all.

~~~
taejo
X.509 certificates don't contain any Turing-complete languages, so the fact
that X.509 interpreters have the same class of bugs as font interpreters, that
supports my point that Turing-completeness itself is not the problem.

