Introducing the Blend font vulnerability
googleprojectzero.blogspot.com
googleprojectzero.blogspot.com
Also, lots of people simply pirate their fonts from googling around "fontname ttf free download", I wonder how much malware hides in these - given that I somewhere have around 16 or so copies of some exotic Adobe font in various formats, one buggier than the other.
Like the article says... that code got around back in the day.
US warez forums always seemed civil, cyberlocker links stayed up for years, malware was not common - German boards like boerse.bz (R.I.P.) and others had to invent "link crypters", websites hiding links to Rapidshare, Mega and other cyberlockers because the users from the boards would abuse-report each others' links. Or they'd invade other boards and post malware-loaded cracks.
Would it be technically feasible to just throw out the old font formats and make a new, more limited format that's just a list of Bezier curves without all the Turing-complete stuff and rarely used features, then convert all the most widely used fonts, and finally schedule TTF for deprecation?
I believe Google Fonts serves the hinted version only to Windows desktops, to save bandwidth for all the other platforms that don't need/want it. I think for many of the fonts the hints are actually auto-generated via the same code that would do it automatically to a non-hinted font on Linux.
The fix is to de-turingify the font parsers. Put hard limits on how much resources any font script can use. There's probably a paper out there on how to virtualise just one part of your program - in this case the font rendering functions. Replace all function calls with RPC calls to a service running on a micro VM. If the VM crashes, pop up a message box "this font is bad" or something.
The stack actually has a hard limit of 48 entries, but the code ensuring that the limits will be adhered to had bugs.
I see two problems with a VM approach: Font handling is performance critical code. You will have to do lots of input validation for the data that is produced, which actually is the reason for the bugs in the original code. Preventing a VM being exploited through executing it in another VM also seems kind of ironic.
What I think might be a good idea is to convert old formats/format versions into newer smaller formats/format versions inside a VM. This way you will still have speed, backward compatibility and you don't need to write additional input validation.
Yeah, I like this. Like LLVM for fonts. Generate an intermediate representation inside a sandbox. Validate the IR. Output and cache a high-speed font for your platform. It might have all sorts of LLVM-like benefits in terms of compatibility and optimization, on top of the security win.
There's a table in the middle of the page. It's larger than my screen. Attempting to scroll it instead triggers navigation to another post entirely because assholes have taken over the web.
If you're clearing cookies manually, at the end of the session, or using some extension to avoid being tracked, this means the warning will show up every time, on basically every popular website you visit.
It's even more ironic to consider that some ad-blocking lists now include element-hiding rules to overcome to those prompts as well (fanboy's "annoyances" list contains many rules for that).
there is no other explanation. 9 out of 10 exploits exists because of adobe code.
1. It is just staffed with mediocre engineers.
2. Have bad QA practices.
3. Low morale?
4. Poor regard for their end customers?
5. Bad management?
6. Heavy focus on profits/revenue vs. quality?
It's only discouraged if the story has already had significant attention [1]. Otherwise, assuming the story is high-quality, it's a good thing to do, because it reduces the randomness in what gets traction on HN.