On Mon, 2015-06-29 at 20:55 +0100, Stephane Chazelas wrote: > $TERM is already passed but only when a pty is requested. Which is by far not the only use case of ssh. Actually there are many major use cases where no pty is involved at all (and where ssh serves just as a crypto transport layer), but where these variables may still have an effect. One may of course consider programs that interpret such variables when no pty is connected buggy,... but I guess that's simply the world as it is. I guess there are a countless scripts, which e.g. use the presence of such variables (and/or their content) to decide whether to add terminal escape sequences (again, may be considered buggy, but that's as it is). But if there is actually no terminal, then these sequences may break further parsing and change expected (and possibly security relevant) behaviour on the server side. > 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 I guess this would improve things a tiny bit, but I still think we'd unnecessarily tickle the dragon's tail by doing so. And what seems to be rather like a strategy to cope with difficult sysadmins, is IMHO not enough justification to implement this change for which no-one can safely say whether or not it has any problematic impact in certain environments. > 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). What was actually a little change (as every even non-decent sysadmin can revert it within seconds) provoked an outcry by some people as if this would cause the world's end. Colin didn't resist the pressure and in the end I've been quite heavily criticised. So I guess you can imagine what would happen if you demand to go to the safe default of not sending/accepting anything. > 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. As I've said,... I don't think we can really forecast whether or not some script uses any of these variables in a way that may be used for attacks or simply break things. I don't say that I know a program where this is possible, but I think no one could really blame a script hacker if he uses those variables (as they're nowhere reserved). For XTERM_* it may seem obvious that these would "belong" to XTerm. But then imagine what comes next, as I've said VTE. There may be people who never heard about "VTE" and use the acronym for something completely different. > TZ is another one that would make sense to pass across but it's > even more dangerous than LC_*. Sure... very much more dangerous... > 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. And even if one would assume, that it may be highly unlikely that SSHENV_* vars are already used somehow... what would we really get by that? Either programs would then need to understand e.g. SSHENV_TZ... rather unlikely that this happens on a broad base. Or the vars would need to be reassigned to their canonical name within the session, and this makes the whole thing useless again (or may simply not work due to permissions). > It would probably make sense to be more restrictive when there's > a ForceCommand than when there's none and the The ForceCommand option wouldn't be enough... there are other ways in SSH to restrict the executed commands. 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. So in the end we cannot generally predict whether the user could have set env vars anyway or not. Long story short, a change like what's been requested in this bug may seem subtle, and not being very security relevant. But that's a big misapprehension. Further, I think we should try not to deviate[0] from upstream behaviour even more as we already do (and the existing cases are already questionable enough from a security PoV). If at all, such requests should perhaps first discussed upstream, but I guess their point is clear in that case. Cheers, Chris [0] With the exception of cases where we'd just harden things more, e.g by disabling unsafe algos per default and that like. Such changes cause at worst immediate breakage (which would be immediately noticed),... but no possibly hidden issues.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature