[This was originally published on RiskBasedSecurity.com.]
On February 5, the Cisco Talos research team published an advisory covering several vulnerabilities in the Graphite (a.k.a. libgraphite) project. According to the vendor page, it “is a ‘smart font’ system developed specifically to handle the complexities of lesser-known languages of the world.” This prompted the media and some in our industry to comment that it is “2016 and a font file can own your computer“.
On the surface, this surprise is understandable, as the general perception of desktop computer systems is that they run an operating system with a couple dozen pieces of software. In reality, that single desktop may represent many hundreds of software packages written or contributed to by thousands of developers. Consumer software has become increasingly complex over the years. The days of a vendor only shipping their products comprised solely of their own code are over. To save time and adopt standards, companies increasingly use third-party software libraries that essentially plug-in to their own (also known as dependencies). This leads to a single piece of software that renders documents or runs a service being built not on one company’s code, but potentially dozens.
In some cases, that one piece of software can have upward of 100 different libraries bundled within. For those who monitor vulnerability disclosures, and especially those familiar with the severity of library vulnerabilities, the issues in Graphite are not surprising. To demonstrate this isn’t a “2016” thing, here is a brief stroll down ‘Font Vulnerability Lane’, along with their associated VulnDB ID.
If you argue that HTML font processing counts, we can go back to at least 2001-01-30 when IBM Lotus Domino Server had an overflow issue with parsing font size specifiers (7164). If you are more liberal and count the X Server that ran on IRIX back in 1999, there was a font path manipulation issue that allowed local attackers to gain privileges (11083). Even end users were facing font-related problems back in 2002, when Netscape Composer had an issue with font tags and the face attribute, leading to an overflow (59752), as well as a WDefaultFontCharset Java class that contained an overflow (60134).
For the purists in this argument, who say that isn’t quite the same as the Graphite issues from days ago, no problem! The XFree86 font libraries were said to have multiple overflows on 2003-08-30 (10249) which is the same issue we’re seeing again today, but making the headlines. From there, we enjoyed a steady stream of font-related vulnerabilities, that can be enjoyed in a cherry-picked decade-long timeline:
| 2004 | We saw Microsoft Word and Wordpad vulnerable to a font converter overflow (12375) |
| 2005 | Java, under Sun’s development, was vulnerable to a font deserialization DoS (20526) |
| 2006 | Apple QuickTime found itself vulnerable to a to font information processing overflow (25516) |
| 2007 | Electronic voting vendor Sequoia had a vulnerable voting machine when reading cartridge font files (58055) |
| 2008 | PHP, a prevalent programming language for web applications, had an overflow in font file handling (47798) |
| 2009 | A bad year for Web Browsers and font issues: Apple Safari (54974), Mozilla Firefox (55846), and Opera (59359) |
| 2010 | Not to be left out, Google Chrome entered the picture with a font processing issue (69168) |
| 2011 | Buy one Microsoft OS, get at least seven font processing vulns free! (70821, 71776, 72919, 76219, 76220, 76843, 76900) |
| 2012 | The Font Uploader Plugin for WordPress shows that even the little guys should fear fonts (82657) |
| 2013 | Java, now under Oracle development and on “3 billion devices”, is the font processing that keeps on giving (91204) |
| 2014 | Around 50 different font-related vulnerabilities disclosed in a single year (trust us) |
While this certainly shows a good sampling of a few font-related vulnerabilities of their first decade, it is interesting to consider where the more serious issues reside, and the number of people affected. More specifically, while we know Windows and Adobe are prevalent on end-user desktops, font processing issues that are found in libraries have the potential to be even more severe, and more widespread.
A single font vulnerability in WebKit (76556) could manifest in Google Chrome, Apple Safari, Amazon Kindle e-book reader, the Apple IOS default browser, and the BlackBerry default browser to name a few. With that in mind, consider the following libraries / dependencies, how wide-spread they are, and how many applications across every platform could be vulnerable to such issues. Remember, this is just a brief list to demonstrate the severity:
- Cairo
- FreeType
- GD Graphics Library
- GNU UnRTF
- Ghostscript
- Google PDFium
- Google Skia
- Google sfntly
- International Components for Unicode for C/C++ (ICU4C)
- Java JDK/JRE
- PHP
- Poppler
- Qt
- libwmf
- php-font-lib
- t1lib
Software developers must be mindful of the threat from vulnerabilities in the third-party code they use. In a perfect world, each library would be audited strictly before inclusion to avoid such issues. However, since one of the primary purposes of using these libraries is to reduce development time, that rarely happens. Until such code review can happen, staying abreast of the vulnerabilities disclosed in those libraries is essential.