Phasing out forwarding of locale settings

[Jochen Bern]

On 10.09.21 12:36, Ingo Schwarze wrote:
> 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

Well, *half*-joking, actually. When passing on a user's locale is seen
primarily as a potential attack vector, worse than forcing every which
user to try to master the CLI in the one language chosen by the admin,
then I don't quite see what setting *would* be considered safe enough
for forwarding. *Especially* not $TERM with all its historic baggage, I
guess.

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

I referred to the differences between upstream (and OpenBSD-oriented)
OpenSSH and the distribs' OpenSSH packages myself as well, so yes. It
would likely serve to make *some* distribs incompatible to SendEnv,
though, and from there, "broken window theory" *might* take hold. It'd
have a better chance of triggering the global swing than the upstream
"leading by example" of not AcceptEnv'ing locale settings (which they
already do, pretty much unnoticed, if the current requests are any
indication).

(Note that I'm *not* in favor of stunting env var forwarding, but that
doesn't keep me from pondering how it *could* be done, and how
apparently not.)

> Needless
> to say, passing LC_* is usually *not* useful because defining it
> statically on both sides is usually simpler and more robust.

I have experienced the communication between a German NOC/ops and a
French dev team in an enterprise that had a "just have everyone speak
English" policy. If we hadn't all been IT professionals with years of
experience in pre-locales computers, and using the same prod platform
CLIs consequently would have been as much of a stutterfest as the phone
calls were ...

> 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

While forcing the server to make (fixed global) choices *without* having
any information on the client software's status and the user's native
language will avoid any mismatch ... seriously?

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

I consider it *very* vital that the login on some remote machine doesn't
suddenly talk to me in Turkish just because the guy who installed the OS
liked that better; it's a DoS attack on me as much as falsifying
filenames in the "ls" output is.

(And yes, my current employer had a *number* of IT guys of Turkish
origin in its early days, so that's not a completely outlandish scenario.)

But tell me this: If it is so important that the terminal mode be
communicated correctly, why doesn't any terminal software I know at
least reflect the *current* mode into $TERM, which already *is* both
earmarked for the purpose of passing information about the terminal, and
special-cased by OpenSSH?

Regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20210910/570d59d6/attachment.p7s>