On 2024-05-20 09:00 -0500, G. Branden Robinson wrote: > For grins, and for a data point from elsewhere in GNU-land, GNU troff is > pretty robust to this sort of thing. Much as I might like to boast of > having improved it in this area, it appears to have already come with > iron long johns courtesy of James Clark and/or Werner Lemberg. I threw > troff its own ELF executable as a crude fuzz test some years ago, and I > don't recall needing to fix anything except unhelpfully vague diagnostic > messages (a phenomenon I am predisposed to observe anyway). > > I did notice today that in one case we were spewing back out unprintable > characters (newlines, character codes > 127) _in_ one (but only one) of > the diagnostic messages, and while that's ugly, it's not an obvious > exploitation vector to me.
Going off-topic but I need a clarification. Are you saying that you wouldn't consider writing arbitrary characters to a terminal a security risk ? To rephrase that in the form of a scenario : 1. Attacker crafts file that, when directly or indirectly processed by our program, causes it to include string /s/ in an error message, 2. Victim runs our program. Error message goes to standard error which is written to the victim's terminal. Is there no value of /s/ that could be considered harmful ? > Nevertheless I decided to fix it and it will be in my next push.
