Bug#780797: openssh-server: modifies the user configuration
On 2015-03-20 01:44:06 +0100, Christoph Anton Mitterer wrote:
> On Fri, 2015-03-20 at 00:46 +0100, Vincent Lefevre wrote:
> > The fact is that Debian doesn't use non-standard LC_* variables.
> People may run *any* software, including their own homebrewed stuff.
So, it's even easier: when the admin installs some software using,
say, LC_ALLOW_ARBITRARY_ACCESS, he can change the sshd config to
disallow this variable.
But any software can also have specific problems with standard locales
variables. As an example, the admin may allow a user to run some
script via SSH. However the script works by filtering some output
messages and only works with English messages, which correspond to
the default locales on the system. If locales variables are passed,
the user may choose another language, so that the script will not run
correctly and may bypass restrictions. Similarly, changing LC_NUMERIC
may change the decimal separator, and in particular how numbers are
parsed, which can be problematic.
So, really, if you want to make sure to avoid problems with the
default config, then no variables should be accepted. If you assume
that the admin does a bit of work, then accepting LC_* should be
safe.
On the other hand, not being to pass the charmap (which needs a
non-standard variable for portability) could be a security issue:
for instance, outputting UTF-8 sequences in an ISO-8859-1 terminal
may change the terminal configuration, and even send some data to
the printer (which may be a public printer).
> Also, "LC_" isn't really that "reserved",.. someone could take it as
> "LocalCode" and have a variable like "LC_ALLOW_EXECUTION".
It is not reserved, but the "LC_" prefix already has some well-known
meaning. Reusing it for something else is a bad idea.
Moreover, in general, using short prefixes is dangerous as this
increases the risk of clash between different programs, and in case
of clash on some variable related to security, you have a potential
vulnerability.
> > If there's a risk of security vulnerability, it probably comes from
> > the standard variables used by the system: by passing an invalid
> > value (with special characters, or a very long value), the user may
> > trigger a bug that might let him run arbitrary code. So, it would be
> > even better to disallow these standard variables.
> Actually I'd agree (see above). While upstream makes many security
> questionable choices (e.g. still allowing very weak DH groups), Debian
> makes even more questionable things ;-) ... and in that case upstream's
> default of allowing nothing is simply the safest and sanest default.
Yes, it would be preferable to the current (new) situation, which is
rather useless.
BTW, passing standard locales variables is already broken by:
https://bugzilla.mindrot.org/show_bug.cgi?id=1346
> > > Striping "unsafe" / "unknown" env vars is common practise for many
> > > programs (e.g. sudo, suexec and things like that).
> > But these utilities are used by the admin, who can already control
> > everything. By default, an end user cannot use sudo at all. On the
> > contrary, once openssh-server is installed, the user can connect
> > via ssh without a special config from the admin: concerning
> > AllowUsers, by default, login is allowed for all users. That is,
> > the default is permissive.
> Well,...
> a) depends what you mean by "per default"... per default, my systems
> have no users after installation except root and system accounts. ;)
In such a case, with such defaults, you won't be able to ssh into
the machine, so that the AcceptEnv value doesn't matter.
> b) that Debian's SSH config allows any user to login per default
> actually emphasises the need to then harden these things as much as
> possible.
By default the user doesn't have a restricted shell, so that
restricting the environment variables is rather useless (except
the well-known dangerous ones such as LD_PRELOAD).
> c) sudo/suexec/ssh don't strip these envvars because they may or may not
> be used by someone other than root. They strip it because environment
> variables can be dangerous and it's simply sane to do so, regardless of
> the user.
For ssh, it isn't by default (see above).
> And you should notice that ssh may not just be used for interactive or
> non-interactive shell sessions, but also for things like restricted
> command execution, where these things may actually matter.
Restricted command execution needs some specific config by the admin.
If the admin spends time to set up these restricted commands, he can
also adjust sshd_config.
Compare to the common case where the user has a full shell access on
the machine: the admin just needs to install openssh-server, and that's
all. In this case, there should be useful defaults.
> Anyway, ultimately it's up to the maintainers what to do here.
> I didn't expect my proposal (and it's implementation) to cause so much
> noise, especially as it's already quite non-standard to abuse LC_* for
> data passing, and as it's really very very easy to get the old behaviour
> back.
That was the only clean way to pass the charmap.
> My idea was solely to harden things at least bit more, if not doing what
> would be even better, i.e. follow upstream's default in this case.
IMHO, either there should be useful defaults for common use, in which
case the old behavior was satisfactory (though I would have preferred
to accept MY_* variables as the MY_ prefix is conventionally used for
private purpose), or Debian should focus on strict security that would
be enforced by default in every case. But in the latter case, why
doing that just for SSH? There are various packages that are far less
secure than openssh-server accepting LC_* variables (I'm much more
concerning by the lack of check for certificate revocation than the
unlikely local use of some non-standard LC_* variable for a security
context).
--
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: