Phasing out forwarding of locale settings

[Ingo Schwarze]

Hi Jochen,

Jochen Bern wrote on Thu, Sep 09, 2021 at 08:28:27PM +0200:

> What you could ask for *here* is that OpenSSH stops supporting SendEnv /
> AcceptEnv altogether - but I have a hunch that you'll need a much more
> convincing case to get *that* thermonuclear solution.

I realize you may not be serious about this - but just in case
someone thinks you are: that is hardly a solution, and much less a
"thermonuclear" one, because some operating systems and operating
system distributions have been known at various times in the past
for patching features back in after said features had been removed
from upstream software for security reasons.

Besides, passing environment variables may occasionally be a useful
feature in unusual situations for very experienced users who know
what they are doing, especially in configuration stanzas where both
the client host and the server host are tightly defined.  Needless
to say, passing LC_* is usually *not* useful because defining it
statically on both sides is usually simpler and more robust.  But
*other* variables may be worth passing in special configurations.
Passing variables by default, even for users who may have no idea
what is happening and what the security implications are, and *for
all hosts*, certainly doesn't look like a particularly smart idea
to me personally.

As i said earlier, OpenSSH already makes a pretty strong statement
by not only documenting that this feature is off by default (except
for TERM) but also by not even listing it in the "ssh_config"
and "sshd_config" example configuration files, which list various
other options that users are more likely to need knowing about.

I believe i said this before, but it seems people missed it:
What is discussed here has security implications.  Specifically,
if the shell on the server uses a locale that does not match the
mode the client terminal or terminal emulator is using, the client
is susceptible to terminal state corruption attacks that can be
triggered by remote unprivileged users, for example by creating
files with crafted, malicious file names in /tmp/ and hoping the
user logging in remotely will issue a command like "ls /tmp/".
Depending on the client terminal configuration, such attacks can
leverage a wide variety of terminal features - for example, freezing
the client terminal (DOS attack) is often trivial, usually in
multiple different ways, but more elaborate attacks like simulating
or falsifying output or in the worst case, injecting bogus, hostile
keystrokes into the client terminal might sometimes also be possible.

Neither passing nor not passing these variables does anything to
improve security.  You are passing *the wrong data*.  What matters
is the mode the client terminal is running in.  That is not the
same as the locale(1) set in the shell running inside that terminal.
On top of that, as you observed, passing that irrelevant locale to
the server by no means assures that the remote host will accept
it and/or even supports it.

Again, i don't think a technical solution exists.  What matters is
educating users (1) what terminal modes are and why they matter
and (2) that using SSH safely requires considering the terminal
mode on the client side, and the locale on the remote side, before
connecting.  I very much doubt that trying to invent some kind
of magical setting will help with that - quite apart from the fact
that magic doesn't work in the first place.

Yours,
  Ingo