On Sat, Jun 13, 2020 at 10:59 PM Werner LEMBERG <[email protected]> wrote:
> > > I find it a *very* bad idea to have code in FreeType that would > > write to a file. Specially bad if that can be controlled by an > > env-var. > > Interesting. Please explain. Do you fear security issues? > Sorry, forgot to reply to this. Yes, security. I give you a couple of examples: - On a security-sensitive system, even an extra open file handle is an extra tool an attacker can use to mount their attack. Read this epic story: https://threatpost.com/pinkiepie-strikes-again-compromises-google-chrome-pwnium-contest-hack-box-101012/77098/ https://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1.html https://blog.chromium.org/2012/06/tale-of-two-pwnies-part-2.html - A few years ago there was an attempted attack on ChromeOS. Some ChromeOS UI components were using GTK+, which uses Pango. Pango used to have a config file. The default search path for the config file looked in certain directories on the user's home-directory, which is writable to the user. It could also be controlled via an environment variable. The config file could reconfigure where Pango module map was loaded from. The Pango module map pointed to binary modules to load for shaping certain scripts. Pango would dlopen() such modules and look for a specifically named symbols and call those. That's already problematic, because it means that an attacker who finds a way to write files to user's home directory would be able to make the system UI load custom code. On top of that, note that that on Linux / ELF as well as most other systems, binary modules can execute code at runtime linking stage. That means, such attack could run arbitrary code on processes that just linked to GTK+ and initialized it but not even display any text. So when I hear about a system, no matter what it is, that will write to file, controlled via env-vars, and configured through a config file, my immediate response is: - That sounds like hell of a lot of security vectors, for... - A feature that is not even justified to begin with! FreeType clients what to read text. None of this contributes to any of that. While you may be tempted to argue why it won't be a problem for FreeType (for example because it will be disabled by default), I accept that. But that is in conflict with what Armin's stance is on this. I'll expand in the other thread. I'm still hopeful to be able to write that today.
