AcceptEnv LANG LC_* vs available locales

[halfdog]

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