escaping terminal control characters (was Re: backdoor in upstream xz/liblzma leading to ssh server compromise)

[Matthew Fernandez <matthew.fernandez () gmail com>]

On 4/1/24 08:30, Solar Designer wrote:
> On Sat, Mar 30, 2024 at 04:37:48PM -0000, Tavis Ormandy wrote:
> > It was also pointed out they submitted an odd PR to libarchive:
> >
> > https://github.com/libarchive/libarchive/pull/1609
> >
> > In summary, they replaced calls to safe_fprintf() with fprintf() --
> > meaning control characters are no longer filtered from errors. That
> > seems pretty minor, but now that we know they were in the business of
> > obfuscating the presence of backdoors -- seems a bit suspicious.
> >
> > Regardless, that change has now been reverted:
> >
> > https://github.com/libarchive/libarchive/pull/2101
>
> This does look minor indeed - not usable for large-scale attacks, and
> libarchive is quite unique in that it even bothered to filter control
> characters, whereas most command-line tools outputting filenames don't
> bother.  My guess is it could have been an early experiment to see
> whether the project would accept PRs degrading security.
>
> That said, here's an excellent write-up by David Leadbeater on specific
> ways that specific terminal emulators may be usefully attacked with
> control sequences:
>
> https://dgl.cx/2023/09/ansi-terminal-security#vulnerabilities-using-known-replies

Is the currently accepted wisdom that any application printing to 
stdout/stderr should take steps to avoid control characters in the 
output? This is one of those situations where, if my terminal is 
manipulated this way, I’m not quite sure who is to blame. Intuitively it 
does not seem to scale, to require every (even non-security minded) 
application to mitigate this. But on the other hand, maybe it’s not 
possible for terminal emulators to solve without false positives.