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
On September 10, 2021 6:37 AM, Jochen Bern 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 - 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 whoknow>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.There are some subsystems, like git, which pass critical environment variables to the SSH server environment that control its operation. Without those variables, git will be handcuffed. The thermonuclear option is not viable in the long-term. Locale is a different subject, I think. -Randall
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 thisWell, *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 attacksWhile 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>