Bug#790401: openssh: Please pass the XTERM_VERSION environment variable
On 2015-06-29 22:50:59 +0200, Christoph Anton Mitterer wrote:
> On Mon, 2015-06-29 at 20:55 +0100, Stephane Chazelas wrote:
> > 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.
> Well, it was myself who brought up another bug not so lang ago, where I
> tried to have Debian's ssh restrict the list to at least the well
> defined LC-vars and not LC_* (which of course doesn't solve the problem
> you mention here).
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.
I wish SSH could pass the charmap, so that the LC_* hack would no longer
be useful.
> > 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.
> Which has in principle the same problem: SSHENV_* is no where really
> reserved for that purpose.
A SSH user should read the SSH documentation. If SSHENV_* is
documented by SSH, then I don't see any problem with that.
If you complain about SSHENV_*, why not complaining about
the existing SSH_ORIGINAL_COMMAND too?
But...
> > It would probably make sense to be more restrictive when there's
> > a ForceCommand than when there's none and the
This would be better.
> The ForceCommand option wouldn't be enough... there are other ways in
> SSH to restrict the executed commands.
Well, also with command="command" in the authorized_keys file.
This would cover most needs.
> I see where you're heading towards:
> You're idea is basically to restrict the accepted env vars whenever the
> user couldn't set them just manually after login... right?
>
>
> Sounds like a nice idea, but doesn't work in practise:
>
> > login shell of the
> > remote user is not restricted (lets you set env vars anyway).
> Nothing prevents the remote server's admin to run special shells where
> env var setting isn't possible.
> He could even forbid execution of any foreign programs (using selinux
> and the like),... so no real way for the client to circumvent this.
IMHO, an admin who takes the time to set up such special shells
and so on, could also take some very little time to change the
sshd Debian defaults.
--
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: