AcceptEnv LANG LC_* vs available locales

[Christoph Anton Mitterer]

On Mon, 2022-05-02 at 08:25 +0000, halfdog wrote:
> > Any concrete example which allows *local* (i.e. client side)
> > execution of code/commands?
> 
> https://unparalleled.eu/blog/2021/20210518-using-xterm-to-navigate-the-huge-color-space/

Interesting one...

> In the end it exploited an integer overflow in libx11, most likely
> introduced in _1986_! The POC injects X11 protocol commands to gain
> full control over your local desktop (injecting keystrokes, key
> logging).

... such a simple feature... where no one would have imagined that it
could lead to such big compromise.



> If I may voice an opinion, instead of having a complicated
> "LANG LC_*" negotiation algorithm, I would more like to see
> an integrated SSH data filter to run all unencrypted data
> through before reaching the other side (both directions).
> 
> -o "TerminalDataFilter [some program]"

I've also had that in mind... thus specifically CCing Damien and Darren
so that they see this.

Can you guys imagine to extend ssh, so that when output is connected to
a terminal, it filters escape sequence (to a varying degree, depending
on some configuration setting)?

The default could be just as is, i.e. no filtering. But there could be
an option that allows to specify escape sequence filtering on a per
host basis.
The more the host is trusted, the more one could allow it.

E.g.
Host absolutely-untrusted.example.org
    TerminalEscapeSequences !all

Host semi-trusted.example.org
    TerminalEscapeSequences !all default

Host fully-trusted.example.org
    TerminalEscapeSequences !all default clipboard


starting from the default ("all"), "!all" would first filtering really
all escape sequences (thereby probably breaking everyhing), "default"
would again allow some sequences that are generally considered safe...
and e.g. "clipboard" would specifically allow OSC52... or "links" which
would enable the OSC that makes hyperlinks, "!colours" could disable
any colour escape sequences, and so on.

There could be one "minimal", which is like "default" but without and
fancy stuff (e.g. no colours) just the bare minimum.


Any one could maybe another option, which controls when that filter
kicks in, e.g. never, when connected to a terminal, always (even if no
terminal is detected).


That would make sanitisation available out of the box for SSH users,
not requiring any thing else that cleans possibly problematic sequences
from untrusted remote nodes.


Terminal authors continue to add such features, that may have a
legitimate use case for local terminals, but could be dangerous when
these are controller by remote machines.
So such filtering on SSH level could be a further guard.


Cheers,
Chris.