Font security 'still a Helvetica of a problem' says Australian graphics outfit Canva Online graphic design platform Canva went looking for security problems in fonts, and found three – in "strange places." On its engineering blog, the Australian outfit explained it's "continuously looking for ways to uplift the security of [its] processes, software, supply chain, and tools," leading it to the "less explored …
Indeed. I think it's insane that even, say, PGN's RISKS website (which, argh, has an expired entity certificate, come ooooon) uses the accurséd @font-face. That has to be one of the worst ideas in CSS. Downloading fonts automatically is just an enormous vulnerability.
CSS is what happened.
To be fair, CSS was in response to MS breaking webpage design as much as possible. (Remember Frontpage?) CSS acted as a way to get some control back.
Then tables fell out of favor and CSS rose as the defacto page formatting.
To this day, I still see no reason to use CSS except in VERY limited circumstances.
And that's just ONE of hundreds of things I hate about modern websites.
I'd heard of font vulnerabilities and assumed it was some sort of buffer overflow because it's always buffer overflows. But they were executables all along? Ew! No wonder people like to block them now. It's like tucking into a bag of crisps and discovering somebody's severed fingernail at the bottom.
No they are not. Remember, the format is fully cross-platform, was invented by Apple, and is used by *nix software as well. The .ttf format consists of a series of tables containing different kinds of data, like metrics, outline geometry (also supporting Adobe Type 1 fonts) and the like. The closest thing to executable code in there would be the grid-fitting instructions, which come from a limited instruction set which is handled by an interpreter. All it can do is adjust things to fit the given rendering parameters, nothing more.
We were discussing TheOldDays, youngster.
Joe W remembered a fairly common error in the Windows world of 25 or 30 years ago, that being "A TrueType font has caused a general protection failure in module setup.exe".
"But how can a TTF cause a GPF?", you ask. Good question. It turns out that the internal file format of TTFs on Windows is (was?[0]) a .DLL. Really. And because of this, corrupt fonts could stomp all over memory and cause GPFs. Worse, carefully crafted .TTF files could be used to compromise a system. There were kernel exploits based on this back in the day.
Dr. Dobbs Journal had a rather in-depth article on how it all worked back in the early '90s, and I believe Byte touched on it, too. Sadly, with today's fucking useless "AI" generated web pages clogging up tehintarwebtubes I can't easily find info to point you in the general direction of ... but I've given you enough to go on should you wish to pursue it.
[0] I honestly don't know if this is still the case or not ... Windows is no longer something I feel a need to spend time with.
I was there from the beginnings of TrueType, when it was still codenamed “Royal”. I used it when it first came out as a Mac-only technology, before the cross-licensing deal Apple made with Microsoft. Remember what they got in return? Some useless PostScript clone that Microsoft had bought; I think neither of them made any use of it.
But that deal was sufficient to make John Warnock so upset, that Adobe finally opened up its proprietary Type 1 format, publishing the book on the spec and also offering Adobe Type Manager software to allow use of those high-quality fonts on desktop screens.
Maybe my search-fu is better than yours, but it took me only a minute to find this article from 1993, entitled “Getting to Know TrueType”. As you can see, the article talks about the tables in the file, and no mention of anything resembling a DLL. As I previously said, the closest thing you will find resembling executable code is the grid-fitting instruction set:
The TrueType instruction set resembles assembly language, complete with opcodes and mnemonics for If/Then constructs, loops, subroutines, and a full complement of arithmetic and logical operations. For example, the MD instruction measures the distance between two outline points and pushes the result on the Interpreter's stack--to possibly serve as part of a further calculation.
Nothing in there about being able to “stomp all over” arbitrary memory—barring bugs in the font loading/rendering machinery, of course.
I came to this article thinking I was going to learn about someone having hacked a font, like others have hacked jpg images. What I actually learn is that there are tools to manage fonts, and it is one of those that is hackable. That is not the same thing.
Then there is the fact that the article evokes three vulnerabilities, but only describes one even though the way the article is written made me believe that I would get a description of all three.
I'm a bit miffed.
>> silently packed with and used to exfiltrate arbitrary files like /etc/passwd from your web server
But isn't that a problem with the font management tools rather than the font file(s) themselves? packing containers with unexpected payloads has been a 'black hat' technique for ever (approximately). Surely it's the management tools/renderers that are the issue rather than the font files/archives themselves?
Yes, but perhaps there is a communication issue here - most people installing a font aren't going to see themselves as "using a font management tool", they are just going to think "I'm installing a font". Therefore if you lead reporting of this with "font management tools" it probably wont be seen as relevant or applicable - even though it is.
The problem seems, to me, to be with FontForge, FontTools and Imagemagick rather than with fonts per se. Headline should have been "Font management tools still have a Helvetica problem with security" - and the issue is, fundamentally, an old problem rather than a novel attack - that of unsanitised (or unvalidated) input leading to unexpected outcomes.
It's an old problem, in that font processing has been full of vulnerabilities since we moved past basic bitmapped fonts (and possibly before then). But it's not just in font-manipulation tools, as an AC post below explains. That specific vulnerability is that some font formats use SVG, SVG is an XML application, and XML parsers are vulnerable to XXE attacks if they permit external entities.
It's a classic case of "there's too much computer in your file format".
There certainly have been other vulnerabilities in font processing, such as overflows and other basic "deadly sins" bugs in various implementations, dating back to at least 1999. That's a quarter-century of "we can't even get fucking fonts right".
FontTools uses an intermediate XML format (TTX) but this is not about that, it's about the parser for the SVG glyphs within a font being vulnerable to XXE. So you could download a font, edit it with font tools to do something benign then convert it back to a font, and it would contain your /etc/passwd
It's a particularly useful article for me because I've also written an OpenType font parser with SVG support, and having just checked as a result of this article it is - er - vulnerable to XXE injection. So I'll go and fix that then.
Anon, obvs.
Pascal Monett> I'm a bit miffed.
For myself, I am extremely disappointed that no-one has mentioned the obvious and related danger of Helvetica Scenario :)
For that matter, Helvetica itself seems to be some sort of memetic worm. Seriously, people. It's not even Palatino.
>>Use Kate or Gedit
nah - vi ftw! or if feeling a little nostalgic, in a microsoft environment, edlin. I didn't think I could remember how to make edlin work but to my horror commands are surfacing in my aged brain. Nurse! Bring the dried frog pills!
>>Wordstar
Nope - Wordstar files could have all sorts of stuff embedded which wasn't text - mostly down to codes required for printing the document... /me has PTSD from making an Epson FX-80 print superscript and subscript from a Wordstar document. You could even do font selection using them if your printer had fonts... shudder... Wordperfect was even worse.... how far have we come in 40 years only to go full circle?
Wordstar was like most of the wordprocessors of the time, and relied on the font support in the printer itself.
To do this, there were internal device independent markers embedded in the document that selected various things like superscript, subscript, bold, underline, strikethrough and different fonts.
To implement these for a particular printer, you had a driver file that you typically loaded as part of your wordprocessor profile, typically at startup.
These driver files contained things like the escape sequences to turn on and turn off each of the features, together with a description of the fonts. For most dot-matrix fonts of the FX-80 era, printers only had fixed-width fonts so the driver only really needed to know the character width and line spacing, but contemporary daisy-wheel printers could have proportional fonts loaded. For these, the print driver also had to know the full font-metrics for the font wheel installed, so these would also be in the driver (Incidentally, nroff on UNIX, which was normally used to drive fixed-width only printers, could also drive printers with proportional fonts, not that many people used it for those).
Printers later than the FX-80 (such as the LQ-80) started adding proportionally spaced fonts, but again, the software worked within the capabilities of the printers, just turning things on and off by escape codes, although like daisy-wheel printers, the metrics for the full font would have to be included.
There were very early attempts to render a page in the computer itself, and transfer the page as a bitmap image using the printer's graphics capability. This started in very early desk-top publishing programs, but I don't know exactly when the main-stream wordprocessing packages started using these types of capabilities. When using a printer like this, there had to be a rendering engine in either the OS or the package itself. This appeared to have been incorporated into the OS in early versions of Windows with GDI in Windows 3.1. It was only when this started happening that the OS needed to know much more about fonts than their metrics.
UNIX printing pre-CUPS was a very hit and miss affair. The software (for example Troff) needed to be able to drive the printers capabilities, making the OS print system mainly a pass-through. With the advent of PostScript things became a bit easier, but the rendering was often still done in the printer (although Postscript does allow embedding fonts into a print if they were not one of the standard fonts that PostScript printers shipped with).
Just prior to CUPS, people started putting together rendering systems using GhostScript (an open source PostScript implementation) to render the image before sending it to a printer using print filters in the System V style print system (a strange beast I'm happy to forget as much as possible). This allowed different types of printer to print graphics-rich pages, and all the application had to do was generate PostScript. This happened around the time of ink-jet printers (I played with it on early Redhat systems and Epson Stylus 400 printers). This became formalised when CUPS was release into the open, and this uses either GhostPrint or GutenPrint (Formally Gnomeprint) to render the page (and now, CUPS is transitioning to prefer IPP in the printers, strangely circular as PDF is an evolution of EPS, or PostScript, moving much of the rendering back into the printer!).
With all of these client side rendering systems, there needs to be font handling in the client computer. The tools for handling scalable fonts is as vulnerable to code problems as anything else.
But getting back to the point, configuring Wordstar for an FX-80 (although why you would need to, because it was one of the standard printers that everything shipped a driver for) is as much like driving a modern priner as an ox-cart is to a Bugatti Veyron.
There were very early attempts to render a page in the computer itself, and transfer the page as a bitmap image using the printer's graphics capability. This started in very early desk-top publishing programs, but I don't know exactly when the main-stream wordprocessing packages started using these types of capabilities.
For years I used a DOS TSR named lq.exe (for "letter quality") which served as a front-end to the FX-80 and did very nice proportionally-spaced fonts by translating the print output to graphics. It came with a number of fonts, including the Correct Typeface, Palatino. I guess it also reflowed lines? Or it came with a printer driver for WordPerfect? I don't remember.
Obviously it was quite a bit slower than printing straight ASCII, but it made for some quite pretty output, by dot-matrix standards. I still have printouts from the mid-1980s generated with it, and they're more visually appealing than the "crap Verdana on a crap HP inkjet" I see from a lot of people.
The most KISS thing is to ditch digital publishing entirely. My typewriter has ONE built-in font -- with zero upgrade potential -- and the only way to "hack" it would be to change the color of the ink ribbon or maybe relabel the keys. (Not sure if the keycaps can be rearranged, but I'm not going to risk destroying it trying to find out!)
For sheer productivity improvement in writing in alphabetic languages, it's true that nothing has yet beaten the introduction of the mechanical typewriter. (See the relevant chapter in Yates, Control Through Communication.)
But there are reasons to do more ambitious typography. Visual rhetoric is A Thing; we even have methodologically-sound studies that demonstrate its effectivity in various contexts, for example, such as corporate financial reporting.
Of course, the Right Way to do it is with a markup language and typesetting software, such as LaTeX.
When most people say "font" they really mean "typeface".
In this case, we're talking about "font" as a term of art in computer software, not as it's used in typography: a software description of a typeface for a particular set of characters, for certain weights, sometimes with variants (such as slanted or italic), and generally plus hinting. Some fonts are also a fixed size. So, no, we're not talking about typefaces, in the article.
So if that's the majority use, is that the actual meaning now?
This is a meaningless question unless you're a linguistic prescriptivist, and prescriptivism is a fantasy.
do the hoi polloi...
"hoi" is the definite article; "the hoi polloi" is redundant.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
