zlacker

[return to "Llama.ttf: A font which is also an LLM"]
1. electr+4e[view] [source] 2024-06-23 14:19:38
>>fugled+(OP)
While cool, technically… From a security perspective today I learned that TrueType fonts have arbitrary code execution as a ‘feature’ which seems mostly horrific.
◧◩
2. px43+5k[view] [source] 2024-06-23 15:11:23
>>electr+4e
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.

◧◩◪
3. anthk+1W[view] [source] 2024-06-23 20:30:44
>>px43+5k
The same with Wav files.
◧◩◪◨
4. plaguu+Ji2[view] [source] 2024-06-24 13:14:39
>>anthk+1W
how can a wav file do anything? isnt it just raw data essentially?
◧◩◪◨⬒
5. dTal+YK2[view] [source] 2024-06-24 15:41:25
>>plaguu+Ji2
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.

[go to top]