openssh unix dev - May 2022 - AcceptEnv LANG LC_* vs available locales

Christoph Anton Mitterer writes:
> On Fri, 2022-04-29 at 12:53 +0200, Ingo Schwarze wrote:
>> [...]
>> > But how could it use this to for code execution on the local
>> > machine?
>>
>> By the remote attacker sending whatever of
>>
>> https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
>>
>> is most inconvenient for you, the user on the client? Good
>> luck making sure nothing from that next to interminable list
>> is inconvenient for you. Other terminals and terminal emulations
>> may have similar lists of in-band controls.
>
> Any concrete example which allows *local* (i.e. client side)
> execution of code/commands?
The closest one I know about:

https://unparalleled.eu/blog/2021/20210518-using-xterm-to-navigate-the-huge-color-space/

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).


But in the end you do not even need that to compromise the client.
Terminals seem to be more designed with usability in mind than
security. That is understandable as 1) they are the main user
interface for text based communication and 2) terminals usually
are used to access local applications, so malicious input or
output most likely means, that it is game over already. So their
attack surface may be huge, not only the terminal code itself,
but also those functions invoked by it, e.g. UTF-8-decoding,
terminal control sequences and clipboard interacting with the
graphics system, window manager, other applications again listening
to those, ...


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]"

On a trusted server, the "LANG LC_*" usecase would be easy to
implement, as the filter could (hiddenly) negotiate whatever
it wants before doing plain input/output forwarding.

Paranoid users may use the filter instead for full data sanitation,
e.g. replacing all non-whitelisted control sequences, all parts
of UTF specification, they will not use anyway, ... with some
escape code (thus messing up the display, but I would rather like
to know when someone is trying to hit me than have a nice display).
Insanely paranoid user may even think of implementing an application
layer firewalling for terming-data, e.g. blocking unexpected
(e.g. very large) copy&paste inputs, whitelist the commands allowed
to be sent to the server, warn on known dangerous commands
(tail -f /var/log/syslog),  ...

Kind regards,
hd

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.