Re: [TUHS] Re: A fuzzy awk. (Was: The 'usage: ...' message.)

[Frederic Chartier]

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.