On Tue, Aug 04, 2020 at 10:23:57PM -0700, Ethan Rahn <ethan.rahn@xxxxxxxxx> wrote: > On Tue, Aug 4, 2020 at 3:41 PM raf <ssh@xxxxxxx> wrote: > > > On Tue, Aug 04, 2020 at 01:29:52AM +0200, Thorsten Glaser < > > t.glaser@xxxxxxxxx> wrote: > > > > > On Tue, 4 Aug 2020, raf wrote: > > > > > > > In such cases, this vulnerability can be mitigated by > > > > the use of an ssh-specific command whitelisting control > > > > such as: > > > > > > Probably just as easy: give the user a restricted shell > > > (/bin/rmksh) as shell and set their PATH etc. suitably, > > > to not include any other commands. > > > > > > bye, > > > //mirabilos > > > PS: Full disclosure: I’m the mksh developer > > > > I've thought of a valid use for this kind of behaviour > > that someone might actually be relying on. :-) > > > > scp sourcefile remoteserver:'`[ -d /a/b/c ] || mkdir -p > > /a/b/c`/a/b/c/targetfile' > > > > (i.e. ensure that the destination directory exists before writing the file > > to it) > > > > cheers, > > raf > > > > It seems that there are a few camps here: I'm not sure that they are all necessarily different camps. > * The scp power users - this camp believes that scp supporting backtick > notation is fine and that running arbitrary commands is a perfectly fine > thing to do. > * The restricted shell users - this camp believes that scp supporting > backtick may not be the best, and there are various restricted shells which > can prevent this. Power users may belong to this camp. Command whitelisting and/or restricted shells can allow authorised uses of backtick shenanigans while disallowing unauthorised uses of backtick shenanigans. I think these are the same camp. Some users are allowed to run arbitrary code. Other aren't. They can coexist. > * The novice users - this camp is surprised to find that scp can be used to > run commands. Once they understand that the server runs "scp -t" it makes a > little more sense. I really do think that the novice/default user is someone who also has interactive ssh access and so there's no problem. Whatever they can execute via scp with backtick shenanigans, they could more easily execute with ssh itself. The problem is when, for example, you only have scp/sftp access to a remote server, such as your bank, and you use WinSCP to transfer transaction files to them to be actioned (people do this where I work), and the bank hasn't properly protected themselves from this "vulnerability". I really hope all banks do take this vulnerability into account (e.g. by just supporting sftp). It matters a lot for them. But it's an issue for the bank / remote server, not an issue for the user who doesn't and shouldn't need to know anything about this (in the banking case). It's not novice users that need to think about this. Most novice/default users have general ssh access and they are just using it to use scp. > The problem that I see here is that this is not going to be obvious to > novice users. If you read the man pages ( https://man.openbsd.org/scp.1 ) I > don't see anything that suggests one could use backticks nor run shell > commands. If the solution to this is that the openssh team includes this as > a note in the man pages and posts under their security page that they are > clarifying that behavior I think that would be fine. Where this is going to > cause pain is if there are novice users who want to have a fileserver ( or > an account ) which disallows ssh access, but allows scp to send/receive > files. Those users are likely going to be bit by this. I don't think they will, because, if they want to disallow general purpose ssh access (i.e. shell access), then they must discover and implement forced commands. I think that's the standard way to prevent general shell access via ssh (at least that's what my government's cyberspooks recommend). Once they are administering an ssh server and implementing forced commands, they are no longer a novice user, surely? But yes, more documentation is always a good idea in my opinion. The question is where it should go. You also have to remember that novice users are not going to try to compromise their remote server using this technique. They're novice users, not malefactors. They are not going to try this, and even if they do, they are only doing things that are are allowed to do. > I understand that the openssh team is not interested in making changes to > scp, but would a clarification on this being intentional behavior be > possible? Then the novice users could account for this in their restricted > shell setups. That sounds sensible. I think something should be done to make the world realise that this CVE isn't important in most cases. But its writeup seems OK in that respect. I think it's a shame that there's a CVE out there that makes scp look bad, when it's really fine in most cases, and in cases where it's not fine, there are solutions to mitigate it. Perhaps the scp manpage could reference the CVE and list a few tools that can mitigate the problem, or just reference the CVE and mention forced commands. But such documentation might not even belong in the scp manpage itself. Perhaps it belongs whereever people searching for CVEs will come across it. Although I agree that it would be cute to put the "mkdir -p" example in the scp manpage, and reference the CVE, and refer the reader to the forced command information in the sshd_config manpage. I'd be happy to supply an scp manpage patch if there's any interest in using it. Just let me know what I should include. But maybe it doesn't belong there. > Cheers, > Ethan cheers, raf _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
