12

I got curious about how to scan or assess the risk of a particular font file before deploying it to hosts. First line of defense, of course, is to make sure that our hosts are patched against any TrueType font vulnerabilities.

I read the excellent research from Google Project Zero and it seems like it is worth understanding risks from fonts. I also read the answer from Tom Leek that suggests (very sensibly) trying the font on Linux before trying it on Windows because:

it would be very hard to craft a "malicious font" which can install a virus on a Windows system, but otherwise works "correctly" on a Linux system

Finally, I installed a python library (FontTools) that allows a conversion from a .ttf to a human-readable .xml file. In the resulting file, there are hundreds of lines of assembly code as a "hinting mechanism" exists in each .ttf file. It is into this assembly code that an attacker would insert exploits.

For further investigation, I would like to compare a known bad .ttf file, like the ones that were used to exploit font handling vulnerabilities, with a known good .ttf files. I imagine it would be difficult to spot the differences without intimate knowledge of assembly, but I'd like to have a look, or at least hear from someone here if such a thing is possible. So, the question is: does anyone know of a way to analyze .ttf files for suspicious commands and does anyone know where to get a .ttf file used to exploit font handling vulnerabilities.

Anders
  • 64,406
  • 24
  • 178
  • 215
mcgyver5
  • 6,807
  • 2
  • 24
  • 45

1 Answers1

4

This is an interesting question. Font files are like other media files which might be abused by malware or within exploiting attempts.

Detecting malicious blocks in such media files would follow a signature-based approach: You or your antivirus software would be looking for suspicious pattern.

I'm not aware of a public compilation of malicious code in font files. You might have to compile your own with the help of public vulnerability databases and exploit databases.

Opening an untrusted file on another platform might be able to detect defects without exposing the environment. That is because exploit code usually targets a specific platform and is not possible to succeed on others. A misbehaving font file might then be an indicator for an attack attempt.

Converting a font file from one format to another is basically what a proxy would do (an application gateway is doing this with protocols). A strict implementation would detect misbehavior and fail the conversion. A less strict implementation would ignore the malicious parts and generate a valid file without remaining dangers.

Marc Ruef
  • 1,060
  • 5
  • 12
  • 1
    Malicious code might have signatures that are detectable thus we see that payloads sometimes are encrypted until used to avoid exposure and removal. We had some un-verified success with the method of slicing up a file in thin slices of data and calculating how random each slice is. If you find a few slices that show a very high random value in files that should not have encrypted sections it is a red flag. – Simply G. Jun 03 '16 at 05:57
  • 1
    Any format that allows hiding away blocks of data inside is dangerous. It can always be decrypted/triggered/run by a secondary piece of code, thus creating an attack vector by two pieces that by themselves raise few alarms. – Simply G. Jun 03 '16 at 06:00
  • The Project Zero effort is ongoing: http://googleprojectzero.blogspot.com/2016/06/a-year-of-windows-kernel-font-fuzzing-1_27.html – mcgyver5 Jun 27 '16 at 22:13