On Fri, 2015-03-20 at 00:46 +0100, Vincent Lefevre wrote: > Unfortunately, some admins want to stick with Debian's default config > (even when this config has a well-known security vulnerability[*]). Well to be honest, apart from the fact that many people may not consider AcceptEnv as security critical (I'd say it one cannot generally tell and it could be), you'll always find at least someone who doesn't agree with making things better and/or progress. That's why we've had people that whined when SSLv2 was disabled, the same with SSLv3, or when wk disabled the 100 years old legacy PGP2 format in the gnupg 2.1 master. I agree, that one shouldn't intentionally break peoples setups, but here it's really very easy for people to get the previous behaviour back (just change the option). So quite frankly, I understand that this change should be somehow better documented, but apart from that, I don't understand the big problem with it. Debian could have just changed back to follow upstream's default of "nothing", given that the LANG and LC_ vars actually may change the behaviour of programs, which in turn could be [not] intended for security reasons (e.g. when commands are enforced in SSH) this wouldn't be that dramatic change either. If you want a system that never changes - don't update. ;) > The fact is that Debian doesn't use non-standard LC_* variables. People may run *any* software, including their own homebrewed stuff. Security-wise it's simply not acceptable to say we have a list of software which isn't vulnerable to something, and in order to be secure, we simply define that no one uses other software. > > > > and both is done for good reasons (security). > > > I don't see how the change could improve security. > > Just because you don't know a program which uses > > LC_ALLOW_ARBITRARY_ACCESS to allow "breaking out" the program doesn't > > mean there is none. > > This doesn't happen in Debian. Or give some package name... Again, see above. Sane security doesn't work by just prohibiting those well known cases which would break security - it works by just allowing what's known to be secure. Also, "LC_" isn't really that "reserved",.. someone could take it as "LocalCode" and have a variable like "LC_ALLOW_EXECUTION". > 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. But if I'd have asked for that, I'd have definitely started a flame war on d-d, with people proclaiming this the end of Unix/Linx ;) > And if you assume that a program can use LC_ALLOW_ARBITRARY_ACCESS > for some obscure reason, why not assuming that a program can behave > in a special way with special values in standard locales variable? Well as said, it's not really excluded that any program changes it's behaviour in a tricky way depending on the LC/LANG vars set,... I have seen far more obscure and weird ways people used for attacks. But at least, the ones in the list now are well defined (see e.g. locale(5)),... so yeah... it's a trade off. > > 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. ;) 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. 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. 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. 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. 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. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature