6 ms·

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

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

samwillis 2y 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.
- asau 2y ago
  [dead]
- electric_mayhem 2y 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?
- turnsout 2y ago
  The risk is that you could have the text content say one thing while the visual display says another. There are social engineering and phishing risks.
  - alexvitkov 2y ago
    If you control the font, you control the content as well, I don't see the attack vector.
    - socksy 2y ago
      Certain design tools type sites like Canva or Pitch allow you to upload fonts and obviously control the content. They are frequently used by phishers to make official looking phishing pages on a trusted source, leading to a cat and mouse game where the companies try to catch phishing like indicators in the content and flag them up for human review or block immediately. In that case being able to show arbitrary other text would definitely be a hindrance because the scanning software typically looks at the data stored in the database. However I think you don't need a Turing machine to exploit this — you could have a single ligature in a well crafted font produce a full paragraph of text. Perhaps there's an alternative vector where someone's premade font on a site that doesn't allow font uploading can be exploited to make arbitrary calculations given certain character strings. Maybe bitcoin mining, if you could find a way to phone home with the result
    - turnsout 2y ago
      If you can trick someone into installing the font, you can now control what they read. Unfortunately a lot of hacks involve the user doing something dumb and avoidable. If this font format is successful, then given enough time, it will become legacy. People won't be as vigilant about it, and they won't understand the internals as well. This is why TIFF-based exploits became so common 20-30 years after TIFF's heyday.
- xg15 2y 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 2y 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.
    - xg15 2y ago
      Normalizing the complexity doesn't make it go away. Ideally, I'd like not to execute any kind of arbitrary code when doing something mundane as rendering a font. If that's not possible, then the code could be restricted to someting less than turing complete, e.g. formula evaluation (i.e. lambda calculus) without arbitrary recursion. The problem is that even sandboxed code is unpredictable in terms of memory and runtime cost and can only be statically analyzed to a limited extent (halting problem and all). Additionally, once it's there, people will bring in libraries, frameworks and sprawling dependency trees, which will further increase the computing cost and unpredictability of it.
      - simonw 2y ago
        That's why I care so much about WebAssembly (and other sandbox) features that can set a strict limit on the amount of memory and CPU that the executing code can access.
        Lockal 2y ago
        Exactly that! And speaking of quotas, nobody can explain, why Ethereum Virtual Machine-like quotas were not enforced in the standard. Imagine that you download a .odt/docx/pdf form with embedded font in LibreOffice in 2025. You start to type some text... And font start to saturate FPU ports (i.e. div/sqrt) in specific pattern. Meanwhile some tab in browser measures CPU load or port saturation by doing some simple action, and capture every character you typed.
- Hizonner 2y 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.
- kenferry 2y ago
  Why do you say that? Security exploits involving fonts are extremely common.
px43 2y 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.
- anthk 2y ago
  The same with Wav files.
  - plaguuuuuu 2y ago
    how can a wav file do anything? isnt it just raw data essentially?
    - dTal 2y ago
      I'm pretty sure it can't. There's nothing in a WAV file that's meant to be executed. A quick google turns up a DirectX vulnerability from 2007 (a validation error that's not inherent to the WAV format per se), and a recent case of WAV files being used to conceal malicious payloads (but coupled with a loader). Having said that, the "arbitrary code" found in TrueType is not really arbitrary either - it's not supposed to be able to do anything except change the appearance of the font. From a security standpoint, there's no theoretical difference between a WAV and a TTF font - neither can hurt your machine if the loader is bug-free. Practically speaking though, a font renderer that needs to implement a sort of virtual machine is more complex, and therefore more likely to have exploitable bugs, than a WAV renderer that simply needs to swap a few bytes around and shove them at a DAC.
      - px43 2y ago
        No, TTF is fully turning complete. Maybe I should have specified that in the original post. WAV is just "vibrate speaker this way" over and over again.
rft 2y 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 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=cmplxrndexamples&site_id=nrsi https://scripts.sil.org/cms/scripts/page.php?id=cmplxrndexam...
oopsallmagic 2y 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.

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

samwillis 2y 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.

asau 2y ago
[dead]
electric_mayhem 2y 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?
turnsout 2y ago
The risk is that you could have the text content say one thing while the visual display says another. There are social engineering and phishing risks.
- alexvitkov 2y ago
  If you control the font, you control the content as well, I don't see the attack vector.
  - socksy 2y ago
    Certain design tools type sites like Canva or Pitch allow you to upload fonts and obviously control the content. They are frequently used by phishers to make official looking phishing pages on a trusted source, leading to a cat and mouse game where the companies try to catch phishing like indicators in the content and flag them up for human review or block immediately. In that case being able to show arbitrary other text would definitely be a hindrance because the scanning software typically looks at the data stored in the database. However I think you don't need a Turing machine to exploit this — you could have a single ligature in a well crafted font produce a full paragraph of text. Perhaps there's an alternative vector where someone's premade font on a site that doesn't allow font uploading can be exploited to make arbitrary calculations given certain character strings. Maybe bitcoin mining, if you could find a way to phone home with the result
  - turnsout 2y ago
    If you can trick someone into installing the font, you can now control what they read. Unfortunately a lot of hacks involve the user doing something dumb and avoidable. If this font format is successful, then given enough time, it will become legacy. People won't be as vigilant about it, and they won't understand the internals as well. This is why TIFF-based exploits became so common 20-30 years after TIFF's heyday.
xg15 2y 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 2y 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.
  - xg15 2y ago
    Normalizing the complexity doesn't make it go away. Ideally, I'd like not to execute any kind of arbitrary code when doing something mundane as rendering a font. If that's not possible, then the code could be restricted to someting less than turing complete, e.g. formula evaluation (i.e. lambda calculus) without arbitrary recursion. The problem is that even sandboxed code is unpredictable in terms of memory and runtime cost and can only be statically analyzed to a limited extent (halting problem and all). Additionally, once it's there, people will bring in libraries, frameworks and sprawling dependency trees, which will further increase the computing cost and unpredictability of it.
    - simonw 2y ago
      That's why I care so much about WebAssembly (and other sandbox) features that can set a strict limit on the amount of memory and CPU that the executing code can access.
      - Lockal 2y ago
        Exactly that! And speaking of quotas, nobody can explain, why Ethereum Virtual Machine-like quotas were not enforced in the standard. Imagine that you download a .odt/docx/pdf form with embedded font in LibreOffice in 2025. You start to type some text... And font start to saturate FPU ports (i.e. div/sqrt) in specific pattern. Meanwhile some tab in browser measures CPU load or port saturation by doing some simple action, and capture every character you typed.
Hizonner 2y 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.
kenferry 2y ago
Why do you say that? Security exploits involving fonts are extremely common.

px43 2y 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.

anthk 2y ago
The same with Wav files.
- plaguuuuuu 2y ago
  how can a wav file do anything? isnt it just raw data essentially?
  - dTal 2y ago
    I'm pretty sure it can't. There's nothing in a WAV file that's meant to be executed. A quick google turns up a DirectX vulnerability from 2007 (a validation error that's not inherent to the WAV format per se), and a recent case of WAV files being used to conceal malicious payloads (but coupled with a loader). Having said that, the "arbitrary code" found in TrueType is not really arbitrary either - it's not supposed to be able to do anything except change the appearance of the font. From a security standpoint, there's no theoretical difference between a WAV and a TTF font - neither can hurt your machine if the loader is bug-free. Practically speaking though, a font renderer that needs to implement a sort of virtual machine is more complex, and therefore more likely to have exploitable bugs, than a WAV renderer that simply needs to swap a few bytes around and shove them at a DAC.
    - px43 2y ago
      No, TTF is fully turning complete. Maybe I should have specified that in the original post. WAV is just "vibrate speaker this way" over and over again.

rft 2y 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 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=cmplxrndexamples&site_id=nrsi https://scripts.sil.org/cms/scripts/page.php?id=cmplxrndexam...

oopsallmagic 2y 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.