[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#790401: openssh: Please pass the XTERM_VERSION environment variable



2015-06-29 18:55:52 +0200, Christoph Anton Mitterer:
[...]
> Sending XTERM_VERSION would be surely not enough, one would at least
> need TERM as well, I'd guess.
[...]

$TERM is already passed but only when a pty is requested. It
should be the same for $XTERM_VERSION or any other variable that
further qualify any terminal identity if ever you decided to
pass them

Note that LANG/LC_* which Debian ssh already accepts is probably one
of the worst one as it affects so many commands. That also
affects bash shell grammar parsing which was why CVE-2014-0475
could be exploited over ssh for instance to run arbitrary
commands on git servers.

XTERM_VERSION seems to be a lot less likely to do harm, but as
you say if we start passing one variable by one particular
terminal emulator, we may end up having to do the same for
dozens other applications. For $XTERM_VERSION, it's not even
needed as there are other ways to get the xterm version.

TZ is another one that would make sense to pass across but it's
even more dangerous than LC_*.

What would be useful however IMO, would be to have a dedicated
harmless env var namespace passed accross consistently in all
ssh deployments (like SSHENV_*) so we can reliably pass
information from the client to the remote command.

like:

At the moment, one can hijack LC_* on many ssh deployments for
that but that's just a dirty hack.

See
http://unix.stackexchange.com/questions/205567/how-to-execute-an-arbitrary-simple-command-over-ssh-without-knowing-the-login-sh

for what I mean.

It would probably make sense to be more restrictive when there's
a ForceCommand than when there's none and the login shell of the
remote user is not restricted (lets you set env vars anyway).

-- 
Stephane


Reply to: