← Back to context

Comment by electric_mayhem

7 months ago

While cool, technically… From a security perspective today I learned that TrueType fonts have arbitrary code execution as a ‘feature’ which seems mostly horrific.

25 comments

electric_mayhem

Reply
rft  7 months ago

(Sadly) this is nothing new. Years ago I wrangled a (modified) bug in the font rendering of Firefox [1, 2016] into an exploit (for a research paper). Short version: the Graphite2 font rendering engine in FF had/has? a stack machine that can be used to execute simple programs during font rendering. It sounded insane to me back then, but I dug into it a bit. Turns out while rendering Roman based scripts is relatively straightforward [2], there are scripts that need heavy use of ligatures etc. to reproduce correctly [3]. Using a basic scripting (heh) engine for that does make some sense.

Whether this is good or bad, I have no opinion on. It is "just" another layer of complexity and attack surface at this point. We have programmable shaders, rowhammer, speculative execution bugs, data timing side channels, kernel level BPF scripting, prompt injection and much more. Throwing WASM based font rendering into the mix is just balancing more on top of the pile. After some years in the IT security area, I think there are so many easier ways to compromise systems than these arcane approaches. Grab the data you need from a public AWS bucket or social engineer your access, far easier and cheaper.

For what it's worth, I think embedded WASM is a better idea than rolling your own eco systems for scripting capabilities.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1248876

[2] I know, there are so many edge cases. I put this in the same do not touch bucket as time and names.

[3] https://scripts.sil.org/cms/scripts/page.php?id=cmplxrndexam...

px43  7 months ago

If you think that's bad, until very recently, Windows used to parse ttf directly in the kernel, meaning that a target could look at a webpage, or read an email, and be executing arbitrary code in ring0.

Last I checked there were about 4-10 TTF bugs discovered and actively exploited per year. I think I heard those stats in 2018 or so. This has been a well known and very commonly exploited attack vector for at least 20 years.

oopsallmagic  7 months ago

It's technically not arbitrary. There is a stack, of sorts, but IIRC it has a depth of six or so, by default. You can do cool stuff with font shaping, but you can't easily execute arbitrary code.

samwillis  7 months ago

Not really, no more so than a random webpage running js/WASM in a sandbox.

The only output from the WASM is to draw to screen. There is no chance of a RCE, or data exfiltration.

  • Hizonner  7 months ago

    > Not really, no more so than a random webpage running js/WASM in a sandbox.

    ... except that it can happen in non-browser contexts.

    Even for browsers, it took 20+ years to arrive at a combination of ugly hacks and standard practices where developers who make no mistakes in following a million arcane rules can mostly avoid the massive day-one security problems caused by JavaScript (and its interaction with other misfeatures like cookies and various cross-site nonsense). During all of which time the "Web platform" types were beavering away giving it more access to more things.

    The Worldwide Web technology stack is a pile of ill-thought-out disasters (or, for early, core architectural decisions, not-thought-out-at-all disasters), all vaguely contained with horrendous hackery. This adds to the pile.

    > The only output from the WASM is to draw to screen.

    Which can be used to deceive the user in all kinds of well-understood ways.

    > There is no chance of a RCE, or data exfiltration.

    Assuming there are no bugs in the giant mass of code that a font can now exercise.

    I used to write software security standards for a living. Finding out that you could embed WASM in fonts would have created maybe two weeks of work for me, figuring out the implications and deciding what, if anything, could be done about them. Based on, I don't know, a hundred similar cases, I believe I probably would have found some practical issues. I might or might not have been able to come up with any protections that the people writing code downstream of me could (a) understand and (b) feasibly implement.

    Assuming I'd found any requirements-worthy response, it probably would have meant much, much more work than that for the people who at least theoretically had to implement it, and for the people who had to check their compliance. At one company.

    So somebody can make their kerning pretty in some obscure corner case.

  • xg15  7 months ago

    It's still horrible, not in a (direct) security but in an interop sense: Now you have to embed an entire WASM engine, including proper sandboxing, just to render the font correctly. That's a huge increase of complexity and attack surface.

    • simonw  7 months ago

      I'm hoping that in a few years time WASM sandboxes will be an expected part of how most things in general purpose computing devices work.

      There's very little code in the world that I wouldn't want to run in a robust sandbox. Low level OS components that manage that sandbox is about it.

      5 replies →

    • Bluestein  7 months ago

      While neat in a "because we can" kind of sense, it really is maddening: Have we gone "compute-mad" and will end up needing a full-fledged VM to render ever-smaller subsets of UI or content until ... what?

      What is the end game here?

      It is kind of like a "fractal" attack surface, with increasing surface the "deeper" one looks into it. It is nightmarish from that perspective ...

  • electric_mayhem  7 months ago

    I’m open to your idea, but can you explain in technical terms why a wasm sandbox is invulnerable to the possibility of escape vulnerabilities when other flavors of sandboxes have not been?