Re: Bug#790401: openssh: Please pass the XTERM_VERSION environment variable
On 2015-06-30 02:53:23 +0200, Christoph Anton Mitterer wrote:
> On Tue, 2015-06-30 at 01:23 +0200, Vincent Lefevre wrote:
> > On the other hand, having the wrong charmap on the other side is a
> > security issue, because remote utilities could send characters that
> > they think to be printable, but are actually control characters /
> > escape sequences due to the wrong charmap interpretation.
> Well but there one knows / must assume at least that this can happen:
> When one remotely accesses a system and processes output from there, it
> must be assumed that there are different locales/etc. and appropriate
> means taken.
This is not possible. Or this would mean that the remote programs
can only output US-ASCII (which is compatible with everything).
> But programs on remote side shouldn't need to assume that they're
> invoked remotely.
>
> But practically,... are there any issues?
Yes, I had issues in the past.
> Most systems likely either use C or UTF-8, and I'd be tempted to say
> it's a their problem if they use some obscure charmap.
Well, ISO-8859-1 is not an obscure charmap and still exists in Debian.
Moreover I fear that with a C terminal, some UTF-8 sequences sent by
the remote side may be interpreted a escape sequences (if some bytes
are in the 0x80-0x9f range).
> > I wish SSH could pass the charmap
> Wouldn't that basically end up in the same concerns?
In what way?
Anyway, the upstream recommendation is to use AcceptEnv, which is
precisely what Debian is doing.
> > A SSH user should read the SSH documentation. If SSHENV_* is
> > documented by SSH, then I don't see any problem with that.
> If one doesn't have a globally standardised list of "reserved" env
> vars, then IMHO the duty is to be set on the responsible side.
The goal is to have SSHENV_* as being reserved.
> > If you complain about SSHENV_*, why not complaining about
> > the existing SSH_ORIGINAL_COMMAND too?
> Theoretically it's the same problem.
> In practise it works, however, for those reason:
>
> 1) hopefully not one accidentally uses these names for other purposes,
> completely unrelated to SSH.
I don't see why. Why would some program accidentally use SSHENV_FOO
but could not accidentally use SSH_ORIGINAL_COMMAND?
> 2) Those special vars are at least consistent across all OpenSSH, i.e.
> it's not a Debian speciality that SSH_ORIGINAL_COMMAND is set, while it
> would be for e.g. XTERM_VERSION
Well, IMHO, SSHENV_* (or similar) should become official upstream...
unless upstream thinks that this is not necessary and the current
AcceptEnv is fine.
> 3) And the main differences with the SSH_* vars is: sshd sets their
> value, it's not really env var passing as in the sense of
> XTERM_VERSION, where an arbitrary value can be set.
According to sshd(8), "The command originally supplied by the client
is available in the SSH_ORIGINAL_COMMAND environment variable."
Since it is supplied by the *client*, it can be quite arbitrary.
> Further, this isn't such an completely obscure scenario: A special
> shell could be something like gitolite.
> It's invoked via ssh, it writes files to the disks, these files are
> perhaps somehow parsed later for authz questions and so on.
> The default behaviour of ssh is to not accept env vars. And the default
> behaviour of most programs/servers, I'd know, is to assume "if the
> envvar is there, then it'save". That's why e.g. apache's suexec deletes
> everything except a few ones which are known to be safely set.
Similarly, the special shell could delete most of the environment when
starting.
> So again, I don't think it's the responsibility of all these people to
> secure themselves against a possibly growing list of var names which
> may or may not affect their programs.
Why not?
BTW, a ssh server can have several users, with different needs:
some will need some environment variable passing, others won't
need that and can always clean up the environment before doing
anything else (say, start with "env -i" or do something similar).
> This examples may sound exaggerated, but I think it demonstrates quite
> well how problematic these things may be; btw. not only in terms of
> security but also data privacy (e.g. do I really want, that arbitrary
> remote sides get to know which local I run, without my explicit
> consent? e.g. whether I'm French, German or Chinese?).
If the user doesn't want to send environment variables, then he
shouldn't use SendEnv in his config file!
Note: I'm not sure whether the /etc/ssh/ssh_config SendEnv settings
can be overridden. If this is not possible, then the SendEnv directive
should be removed from this file. This is not a problem for the user,
who can add SendEnv directives in his .ssh/config file if he wishes
to pass environment variables.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply to: