

Introducing the Blend font vulnerability - daveloyall
http://googleprojectzero.blogspot.com/2015/07/one-font-vulnerability-to-rule-them-all.html

======
mschuster91
Hmm, I wonder if a PDF file is actually needed for a font exploit. What about
the trend of every fucking website now to ship their own fonts?

Also, lots of people simply pirate their fonts from googling around "fontname
ttf free download", I wonder how much malware hides in these - given that I
somewhere have around 16 or so copies of some exotic Adobe font in various
formats, one buggier than the other.

~~~
daveloyall
I like how you're thinking. Also, what about other things derived from the
same codebase?

Like the article says... that code got _around_ back in the day.

~~~
mschuster91
Hiding malware in cracks or pirated content was usual on the warez forums
'round here.

US warez forums always seemed civil, cyberlocker links stayed up for years,
malware was not common - German boards like boerse.bz (R.I.P.) and others had
to invent "link crypters", websites hiding links to Rapidshare, Mega and other
cyberlockers because the users from the boards would abuse-report each others'
links. Or they'd invade other boards and post malware-loaded cracks.

~~~
TheHippo
Boerse moved to boerse.to and afaik there very much alive.

------
csense
"the attackers can choose from any of the existing file formats, most of which
are extremely complex both structurally and semantically, making it very
difficult to get them 100% right in implementation. If we also consider that a
majority of the parsers were in a large part developed in C/C++ several
decades ago, that they are easily reachable via numerous channels (websites,
documents, USB sticks etc.), and that they support extensive, turing-complete
virtual machine environments for running untrusted TTF/PostScript Charstring
programs, it becomes clear that fonts are one of the best imaginable attack
vectors..."

Would it be technically feasible to just throw out the old font formats and
make a new, more limited format that's just a list of Bezier curves without
all the Turing-complete stuff and rarely used features, then convert all the
most widely used fonts, and finally schedule TTF for deprecation?

~~~
anon4
Those features are there because people need them. Also, any new standard runs
into the xkcd 927 problem of "the one standard to rule them all actually
becomes just one more standard trying to compete".

The fix is to de-turingify the font parsers. Put hard limits on how much
resources any font script can use. There's probably a paper out there on how
to virtualise just one part of your program - in this case the font rendering
functions. Replace all function calls with RPC calls to a service running on a
micro VM. If the VM crashes, pop up a message box "this font is bad" or
something.

~~~
legulere
The feature causing the bug in this text is actually an experimental feature
that was removed later on from the standard again and weren't really ever
used.

The stack actually has a hard limit of 48 entries, but the code ensuring that
the limits will be adhered to had bugs.

I see two problems with a VM approach: Font handling is performance critical
code. You will have to do lots of input validation for the data that is
produced, which actually is the reason for the bugs in the original code.
Preventing a VM being exploited through executing it in another VM also seems
kind of ironic.

What I think might be a good idea is to convert old formats/format versions
into newer smaller formats/format versions inside a VM. This way you will
still have speed, backward compatibility and you don't need to write
additional input validation.

~~~
JackC
> What I think might be a good idea is to convert old formats/format versions
> into newer smaller formats/format versions inside a VM.

Yeah, I like this. Like LLVM for fonts. Generate an intermediate
representation inside a sandbox. Validate the IR. Output and cache a high-
speed font for your platform. It might have all sorts of LLVM-like benefits in
terms of compatibility and optimization, on top of the security win.

------
tedunangst
Fuck you, blogspot. Fuck you.

There's a table in the middle of the page. It's larger than my screen.
Attempting to scroll it instead triggers navigation to another post entirely
because assholes have taken over the web.

~~~
TD-Linux
I have hit the back/forth swipes by accident countless times on blogspot. It
makes pretty much any article there unreadable on mobile. Switching to Reader
mode in Firefox is a fix, but shouldn't be necessary in 2015.

~~~
aw3c2
It is _because_ it's 2015 and people have taken a liking in using JavaScript
to do awful things with design for no good reason.

------
gcb0
ok, i'm convinced. Adobe is a front for the NSA.

there is no other explanation. 9 out of 10 exploits exists because of adobe
code.

~~~
electic
some other scenarios:

1\. It is just staffed with mediocre engineers.

2\. Have bad QA practices.

3\. Low morale?

4\. Poor regard for their end customers?

5\. Bad management?

6\. Heavy focus on profits/revenue vs. quality?

------
ollyfg
Off topic, but does anyone know what's up with the
"?hn_email_told_me_to_repost=true" in the url?

~~~
nitrogen
HN will treat a resubmission within a short enough time frame as an upvote of
the original submission. Changing the URL parameters causes HN to treat the
second submission as a new, unique submission. AIUI this is usually
discouraged, but sometimes allowed if a good article disappears from /newest
or the front page too quickly to get a fair chance at being upvoted and
discussed.

~~~
dang
> AIUI this is usually discouraged

It's only discouraged if the story has already had significant attention [1].
Otherwise, assuming the story is high-quality, it's a good thing to do,
because it reduces the randomness in what gets traction on HN.

1\. See
[https://news.ycombinator.com/newsfaq.html](https://news.ycombinator.com/newsfaq.html).

