terminal escape sequences (was: [PATCH] [grotty]: Use terminfo.)

[G. Branden Robinson]

Hi Ingo,

At 2023-08-20T14:03:30+0200, Ingo Schwarze wrote:
> i did not spend the time yet to understand what this discussion is all
> about, and it seems to have very low priority for me, at the same time
> as there are lots of moderate to high priority tasks open for me -
> including, for example, support for lower-case .TH/.Dt and .SH/.Sh and
> for .MR in mandoc plus various other topics, so i'm not likely to look
> at the discussion this mail belongs to soon - oh wait, actually, i
> might have to investigate what is going on here before updating the
> OpenBSD port of groff because if it is dangerous, i might have to
> hardcode -c in our groff port to protect our users from
> vulnerabilities.

Lennart's proposed patch is for the _next_ release of groff.  I don't
think there's any way it can impact the 1.23.0 release.

You did suggest a while back that you'd force grotty's `-c` flag on.  If
you do, don't forget to update the man page.  :)

> I'm not saying that will be needed - but merely that i did not
> investigate yet and that i have a bad feeling about it.

As Nicholas Marriott recently pointed out regarding tmux,[1] it doesn't
"do anything" with these escape sequences (except pass them through).
Similarly, all grotty(1) does is produce them; it implements no code for
reading or executing anything to do with OSC 8 escape sequence
parameters.

> G. Branden Robinson wrote on Sun, Aug 20, 2023 at 01:52:14AM -0500:
> > I guess I need to understand more about the purported hazards of
> > `-r`.
> 
> Fortunately, that part is trivial.
> 
> Essentially, using -r for manual page display amounts to enabling
> remote exploits.  In some circumstances, it may allow manual page
> authors to run arbitrary code as your user ID on your machine.

This sounds like a problem terminal emulator (and virtual console
driver) maintainers needed to solve 25+ years ago.  I don't know of
anything in ECMA-48 that amounts to "reuse this output as input".

Do you?

> In many circumstances, it will cause reliability issues, i.e. remote
> attackers can change the way your terminal shows output (hiding
> information from you or inserting bogus information)

This used to be commonplace when catting binary files in an xterm; the
probability of encountering the "enacs" (enable alternate character set)
sequence by accident was high, and practically no one dismayed by this
knew enough to (blindly) type the interrupt and line-kill characters and
then "tput rmacs" to recover state.

Modern xterm no longer has an "enacs" capability; the DEC ACS feature is
simulated by mapping its modally accessed code points to Unicode
instead, eliminating frustrating character set shift states.

> or interprets what you type (potentially changing the effect of
> commands you are typing into the terminal).

Do you have a concrete example?

> It certainly allows remote DOS attacks, i.e. making your terminal
> unusable.

If a terminal emulator ignores SIGINT, it's got a bad bug.

> If you ever look at manual pages as root - admittedly, i am quite
> careful to never do that on sytems running man-db or groff for manual
> page display, but i occasionally do it on systems running mandoc, and
> i guess many Linux users will fail to be careful about avoiding to run
> man(1) as root - all of the above may turn into remote root exploits.

I think these problems should be addressed, not avoided with folkloric
prohibitions against certain options to less(1).  Folklore is not a
robust defense.  If "less -r" is that bad, its distributors should take
it out.  That might get Mark Nudelman's attention.  But I think this
hasn't happened because it's not really the problem.

> In a nutshell, less -r must NEVER be run on untrusted input, and
> manual pages are a prime example of untrusted input.  I mean, have you
> ever heard about anybody performing a security audit on manual page
> source code, to find out whether the manual pages in question contain
> any malicious code?

The Linux man-pages project scrutinizes the code it presents as
examples pretty closely, but I can't say if it meets your criteria for a
formal audit.[2]  If you mean man page source code per se, that being
the roff language, then (1) GNU troff has run in "safer" mode for years,
disabling formatter features that execute commands or read from
arbitrary file system locations.  Werner Lemberg appears to have
implemented the modern form of this security feature in 1999.  (2)
man-db man has run in a seccomp(2) "security sandbox" since about
December 2017.  No one is better placed than you to say how careful
mandoc(1) is.

> If the answer is "no", or even if it is "well, i assume there may be
> at least some manual pages on my system that have not been audited for
> security by people i trust", then you have to treat manual pages as
> potentially malicious input.

I think we do treat them thus.

> As a matter of fact, i even avoid using less -R for manual page
> display for security reasons.  While admittedly, the -R option has
> been designed such that it ought to be safe, that is only true as long
> as the specific terminal emulator being used doesn't contain bugs that
> mix up escape sequences.

I don't know why people are so tolerant of crap terminal emulators.
Well, I sort of do.  xterm was demanding to maintain, and so for several
crucial years during the height of the Unix Wars, it _wasn't_
maintained, resulting in numerous forks with features of widely
disparate wisdom and quality jammed into it by programmers of varying
levels of ability and interest in code quality.  (And because a
permissive license is the "only true freedom", and most of them did
their work for hire, practically none of them communicated with each
other, and a thousand flowers of pointless incompatibility bloomed.)
Further, standards documents and programming manuals for the line of
terminals emulated were harder to come by (in part because they were
copyrighted and regarded as still commercially viable, I surmise).

Once the Unix Wars were over and every serious shop took up Windows NT 4
or 95, nobody paid anyone to work on a terminal emulator or console
device anymore because those things have no sex appeal.  Every CEO in
Silicon Valley has been too busy touting the next revolution in gestural
communication, voice recognition, "AI" interfaces, etc., to channel any
dollars toward the backward-looking computer interfaces through which
the basic operations of their IT and R&D departments are conducted.
"Will this make the number go up?"  "Can't see how."  "To hell with it."

Multiple hobbyists took one look at xterm's difficult architecture--as I
understand it, it was originally implemented before the X Window System
itself as a terminal _multiplexer_--and decided that starting over from
scratch would produce a superior outcome.  "From scratch."  Most or all
of them took one look at the complexity of the state machine required to
implement ECMA-48, said "tl;dr" and lifted xterm's wholesale, sometimes
filing off comments and trivially renaming variables to conceal its
provenance.  Then, when (mainly) Thomas Dickey found and fixed problems
with that state machine, the clones neglected to port the fixes.  Likely
just because they were lazy, had moved on to other things, or weren't
even paying attention, but possibly also to maintain their pretense of
independent invention.

But, by God, they got the important stuff done: their terminal
backgrounds alpha-blended with their XMMS visualization plugins and
throbbed in time to a house beat.  Terminal emulator development is "a
long plastic hallway where thieves and pimps run free and good men die
like dogs, for no reason."[3]

As far as I can see the only solutions to this are to (1) roll up one's
sleeves and improve the few terminal emulators that are already best of
breed, to tighten them up further; and (2) breathe fire on the rest.

Good luck, Linux console.[4]

> As a software developer, i occasionally test non-standard terminal
> emulators, and then i don't want to have to remember changing my PAGER
> environment variable, so i prefer playing PAGER safely in the first
> place.

Your caution may protect you but it doesn't help the ecosystem much.

Regards,
Branden

[1] https://lists.gnu.org/archive/html/bug-ncurses/2023-08/msg00018.html

[2] In _my_ opinion, a formal audit of man page source examples would
    require a formal language to prove and automatically verify theorems
    about the input, and that is a damned hard thing to do, especially
    in a slap-happy language like C.  I've worked with people for whom
    this is an active field of research.  They're doing it for seL4, a
    microkernel written in C.  (The Haskell implementation of that same
    kernel was validated with much less effort a decade ago or more.)

    https://proofcraft.systems/

    I hope that in another generation or so, this sort of validation
    will be commonplace, and derpy devops people will yammer about
    orchestrating Kubernetes contains to conduct it.

[3] Hunter S. Thompson, _Generation of Swine_
[4] 
https://lore.kernel.org/linux-man/20220320160217.gws42lklp6ishzub@localhost.localdomain/

signature.asc
Description: PGP signature