On 2015-06-30 02:53:23 +0200, Christoph Anton Mitterer wrote: > On Tue, 2015-06-30 at 01:23 +0200, Vincent Lefevre wrote: > > 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. > Well but there one knows / must assume at least that this can happen: > When one remotely accesses a system and processes output from there, it > must be assumed that there are different locales/etc. and appropriate > means taken.
This is not possible. Or this would mean that the remote programs can only output US-ASCII (which is compatible with everything). > But programs on remote side shouldn't need to assume that they're > invoked remotely. > > But practically,... are there any issues? Yes, I had issues in the past. > Most systems likely either use C or UTF-8, and I'd be tempted to say > it's a their problem if they use some obscure charmap. Well, ISO-8859-1 is not an obscure charmap and still exists in Debian. Moreover I fear that with a C terminal, some UTF-8 sequences sent by the remote side may be interpreted a escape sequences (if some bytes are in the 0x80-0x9f range). > > I wish SSH could pass the charmap > Wouldn't that basically end up in the same concerns? In what way? Anyway, the upstream recommendation is to use AcceptEnv, which is precisely what Debian is doing. > > A SSH user should read the SSH documentation. If SSHENV_* is > > documented by SSH, then I don't see any problem with that. > If one doesn't have a globally standardised list of "reserved" env > vars, then IMHO the duty is to be set on the responsible side. The goal is to have SSHENV_* as being reserved. > > If you complain about SSHENV_*, why not complaining about > > the existing SSH_ORIGINAL_COMMAND too? > Theoretically it's the same problem. > In practise it works, however, for those reason: > > 1) hopefully not one accidentally uses these names for other purposes, > completely unrelated to SSH. I don't see why. Why would some program accidentally use SSHENV_FOO but could not accidentally use SSH_ORIGINAL_COMMAND? > 2) Those special vars are at least consistent across all OpenSSH, i.e. > it's not a Debian speciality that SSH_ORIGINAL_COMMAND is set, while it > would be for e.g. XTERM_VERSION Well, IMHO, SSHENV_* (or similar) should become official upstream... unless upstream thinks that this is not necessary and the current AcceptEnv is fine. > 3) And the main differences with the SSH_* vars is: sshd sets their > value, it's not really env var passing as in the sense of > XTERM_VERSION, where an arbitrary value can be set. According to sshd(8), "The command originally supplied by the client is available in the SSH_ORIGINAL_COMMAND environment variable." Since it is supplied by the *client*, it can be quite arbitrary. > Further, this isn't such an completely obscure scenario: A special > shell could be something like gitolite. > It's invoked via ssh, it writes files to the disks, these files are > perhaps somehow parsed later for authz questions and so on. > The default behaviour of ssh is to not accept env vars. And the default > behaviour of most programs/servers, I'd know, is to assume "if the > envvar is there, then it'save". That's why e.g. apache's suexec deletes > everything except a few ones which are known to be safely set. Similarly, the special shell could delete most of the environment when starting. > So again, I don't think it's the responsibility of all these people to > secure themselves against a possibly growing list of var names which > may or may not affect their programs. Why not? BTW, a ssh server can have several users, with different needs: some will need some environment variable passing, others won't need that and can always clean up the environment before doing anything else (say, start with "env -i" or do something similar). > This examples may sound exaggerated, but I think it demonstrates quite > well how problematic these things may be; btw. not only in terms of > security but also data privacy (e.g. do I really want, that arbitrary > remote sides get to know which local I run, without my explicit > consent? e.g. whether I'm French, German or Chinese?). If the user doesn't want to send environment variables, then he shouldn't use SendEnv in his config file! Note: I'm not sure whether the /etc/ssh/ssh_config SendEnv settings can be overridden. If this is not possible, then the SendEnv directive should be removed from this file. This is not a problem for the user, who can add SendEnv directives in his .ssh/config file if he wishes to pass environment variables. -- Vincent Lefèvre <vinc...@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) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
