It's 2016 and a font file can own your computer Cisco-owned Talos has announced a bunch of font library bugs present in apps running on Windows and Linux, affecting client and-server-side machines. The problem is in the Libgraphite library, and means that applications using the library to load .TTF font files can inherit its vulnerabilities. All that's needed for a …
Find the browser option to control downloading fonts, disable it, and then set it to use the default system fonts to render everything instead.
If your browser has Accessibility options, set them to ignore the fonts on the sites & just render in the system default.
The end result is that you get the same clarity of text across your surfing & don't have to constantly zoom in/out to try & find all the stupidly (mal)formed bits.
YES it will sometimes break a site's WebDev's pretty layout, but if they're forcing you to view it with a specific font, they've obviously never gotten past the days of "Best if viewed at $Resolution on $Browser" levels of incompetency & deserve to be mocked out of a job.
Is it the presence of downloadable fonts you object to or some designers' abilities to handle variations in browser rendering the problem?
About the only site I recall doing downloadable fonts is this one: http://www.qsl.net/vk4ba/ It's since been taken over by others, this is what it looked like when I put it up.
It's not a feature I've done much of.
Unfortunately certain sites (tumblr does for instance) seem to be using custom fonts instead of images for the little iconographic action buttons that are so popular nowadays. I'm sure it's more efficient in some sense, but it's going to make those sites a pain to navigate if I have to turn it off.
It's looking more and more I'll have to sandbox my browser in a VM to be able to access most sites with a reasonable level of security.
Even before I went blind & could still see for fonts to matter, I disabled the ability to download fonts from websites as a massive security risk. You have no control over what that supposed "font" package might contain, the system doesn't properly scan it for nasty bits, & if it causes your system to get holed there's not much you can do to fix it. (It CAN be fixed, but it's closing the barn door after the horse has bolted; it's easier to close that door in the first place & never let the font in to begin with.)
As I mentioned in my original post, the fact that you set your browser to ignore the fonts & font sizes on sites to use the system defaults instead means you're never left at the mercy of some dingleberry of a WebDev whom thinks it funny to try to force you to use some bastardized version of WingDings in 6point type, or suddenly shove a 99999point explosion down your optic nerves. You don't have to zoom in/out to see it, you don't have to curse their existence for their choice of fonts, and you're not open to the security nightmare that is the downloading of unvetted code to be run in RING0.
I'm sure that there are valid reasons for wanting a specific font/size/style on a site, but I can't imagine any that trump my security policy of refusing to let that Trojan Horse in through the gates.
It's a bit of a half-arsed report. I have a choice of 2-2 and 3. No mention of them. Did they really look at just one version?
In any case, removing it (2-2) seems to have no effect. LibreOffice continued to render Gentium which seem to be the only font family I had installed that uses it.
here's the changelog for the opesuse package:
libgraphite2-3 - Text categorization library
Mon 21 Dec 2015 12:00:00 GMT
- Version update to 1.3.4:
* Fix Collision Kerning ignoring some diacritics
* Handle pass bits 16-31 to speed up fonts with > 16 passes
* Various minor fuzz bug fixes
* Make Coverity happy
* Add GR_FALLTHROUGH macro for clang c++11
- Upstream moved to github
Wed 16 Dec 2015 12:00:00 GMT
- updated to 1.3.3
* Slight speed up in Collision Avoidance
* Remove dead bidi code
* Bug fixes
. Between pass bidi reorderings and at the end
. Decompressor fuzz bugs
. Other fuzz bugs
Thu 10 Sep 2015 13:00:00 BST
- Version bump top 1.3.2:
* Remove full bidi. All segments are assumed to be single directioned.
* Bug fixes:
+ Decompressor corner cases
+ Various fuzz bugs
Tue 01 Sep 2015 13:00:00 BST
- Version bump to 1.3.1:
* Deprecation warning: Full bidi support is about to be deprecated. Make
contact if this impacts you.
* Change compression block format slightly to conform to LZ4
* Handle mono direction text with diacritics consistently. Fonts
now see the direction they expect consistently and bidi now
gives expected results.
* Fixed lots of fuzz bugs
* Coverity cleanups
* Build now works for clang and/or asan and/or afl etc.
I mean, we all know the desktop security and segregation model is a total mess largely due to starting off fighting over severely limited machine resources and a more pleasant world...
But fonts? A bunch of vectors? I just don't get why they have to be so dangerous 30 years later! XML, for instance, can describe similar data without needing admin privs. Not being a drama queen, genuinely don't understand how one of the scariest computer things should be one of the most mundane, but isn't?
I'm just winging this from memory so i could be easily wrong, but a mere five minutes into being involved with font design (no matter on how amateur a level) one rapidly comes to appreciate the significant difficulty of rendering all font glyphs _just_ the way they were meant in every possible corner case. If I recall correctly, one of the ways they tried fixing that back in the day was incorporating "instructions" into TTF fonts that were supposed to aid proper rendering of that particular font - as in a sort of full-blown virtual machine provided by the font renderer. Fast forward to a decidedly less innocent world today and I suppose you can see the writing on the wall...
TrueType fonts are normally just "a bunch of vectors" but can also contain a whole program. This isn't very common: it's normally use for hinting, and nobody bothers with hinting, but we have a few fonts that use this table to shape the glyphs. Which is ****ing annoying.
Spec is at https://www.microsoft.com/typography/otspec/ttinst.htm, here's a snippet of example code:
PUSHB[3] 23 17 1 /* PUSH : jump1, jump2, rast. version flag */
GETINFO /* get the rasterizer version */
DUP
PUSHB[1] 34
LTEQ
ROLL
SWAP
JROT /* we are at MS rasterizer version 1.7 or higher (> 34) */
PUSHB[1]
As you can see there's a lot of room here for poor bounds checking to do some damage. I didn't read their bug report and I've no idea if the fault they found is in this section, but knowing the spec, I can't see where else it would be.
(We've written our own TrueType font parser due to the holes in the one supplied with the JVM)
(edit: El Reg, a newline at the end of the line means one line break, not two! Sort your editor out. No, not Andrew, the text editor)
(With apologies if you know all of this already.)
In the case of Windows, this all goes back to Windows NT 4.0.
Windows NT 3.x was stable and had lots of advanced features, but it required a pretty big machine at that time. 3.1 (the first release) was huge, 3.5 was better, and 3.51 was - by comparison to 3.1 - faster than a greased rat up a drainpipe. Sadly, when compared with Windows 95, Windows NT 3.51 was still slow.
Microsoft was running out of optimisations that they could feasibly make, and hardware wasn't catching up quickly enough either.
So Microsoft decided to move the GUI into ring 0.
Ring 0 is where the kernel lives. Intel CPUs had two "rings" where the code runs, each with different levels of privilege. In ring 3, the memory and I/O that the code has access to can be restricted to ensure a process can't affect other processes. Ring 0 has unrestricted access to the whole machine. (There are also rings 1 and 2, but earlier Intel processors didn't implement them so we're stuck with just the two rings.)
Moving the GUI code into ring 0 made window painting/repainting faster, so it was a significant improvement. Windows NT 4 felt livelier and nippier than Windows NT 3.51, so in that regard it was a success.
It was also controversial at the time. Windows NT was advertised as the secure version of Windows, and plenty of people were aware that this might not work out so well.
However, at the time there were no practicable exploits. Machines were only ever connected to what we'd now regard as trusted networks, video card drivers came on floppy disks and updates to them were hen's teeth, fonts were things we installed only if an application wanted it. And so on, and so on. Therefore only geeks and academics cared about the possibly impact of the move to ring 0.
The world is a little different now, and we're paying the price for past naiveties....
(In Microsoft's defence, X Servers usually run in ring 0 too, for performance reasons. I wouldn't bet against the Mac OS X graphical stack doing so as well. People like faster, and the customer is always right because he votes with his wallet.)
Like WMF, a font isn't just a bitmap, or even a list of vectors, or a combination of the two.
It contains instructions acted upon by an interpreter.
It's not quite as bad as the WMF fiasco (if you don't know, WMF is basically a collection of function calls to internal Windows vector-drawing functions - I kid you not - which could be cleverly edited to call ANY Windows function, but was later limited to just those that were intended leaving just overflows etc.) but it's still pretty bad.
That only one font library is affected, though, and not things like SDL_ttf or Freetype or similar, suggests that it's just particularly bad coding in that particular library rather than an inherent problem of the file format.
But, yes, why font-hinting requires a virtual machine, I have no idea. I'm sure there are reasons. And I'm equally sure that there would be better ways to deal with them.
But fonts? A bunch of vectors? I just don't get why they have to be so dangerous 30 years later! XML, for instance, can describe similar data without needing admin privs
But XML everywhere makes things slow, especially if you insist on it being well-formed, which the specs say it should be. Thus we have binary file formats with "nasty" things like fields indicating how many bytes are in some section of the file or data fields compressed with zlib or similar. Most of the kinds of errors arising from using these are down to insufficient checks on such fields to make sure that they make sense.
Besides the performance problem, XML isn't a panacea. It can work well for some structured data, but it essentially follows a strictly hierarchical model. There isn't any standard way to model interdependencies between one section of the XML file and another, so it's still possible to get errors where something is essentially declared in one part of the file, but never properly instantiated in another, leading to NULL dereference problems (similar to one mentioned in the article, leading to a crash) if the proper checks aren't included. XML schemas also aren't immune to designers embedding "field length" fields, either (in one way or another; compressed strings often implicitly use this feature).
Finally, I don't think your point about privileges is appropriate here, since neither the article or the vulnerability report mention it. The gist here is that if you can install a bad font file on a server then it can pass that to clients that connect. The bugs have nothing to do with admin rights as such.
If a font is so complicated it cannot be defined in simple terms then drag it out of the font directory and put it in the "Superfont" directory.
Then a simple option to turn off superfonts would be available, and be an obvious signpost for dev's to avoid, if they wish to maintain credibility with the over 100's (IQ that is)
VGA fonts were set by a call to the BIOS (*). I have a collection of them somewhere. I'm pretty sure that some games used custom fonts to display graphics even though they were still in text mode. Can't think of one for sure, but I think that the Kroz series of games might have used this trick.
* http://www.ctyme.com/intr/rb-0143.htm
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
