Re: ssh+svn vs. bash security bug?

Vincent Lefevre <vincent-svn_at_vinc17.net> writes:

> How can this be possible? Do you mean that OpenSSH starts the command
> with bash instead of some exec* function or /bin/sh (which is dash on
> my machines)?

OpenSSH uses the login shell for the user, from session.c:

        /*
         * Execute the command using the user's shell. This uses the -c
         * option to execute the command.
         */
        argv[0] = (char *) shell0;
        argv[1] = "-c";
        argv[2] = (char *) command;
        argv[3] = NULL;
        execve(shell, argv, env);
        perror(shell);
        exit(1);

So an svn+ssh installation can be secured by ensuring that the command
"svnserve -t" is forced and the corresponding login shell is not bash.
Subversion cleans the environment before invoking hooks so any hooks
invoked by svnserve are safe even if those hooks use bash.

A patch to add a no-user-shell option to OpenSSH has been suggested:

http://www.openwall.com/lists/oss-security/2014/09/25/41

However if there is no shell then OpenSSH either has to parse the
command itself, which is non-trivial, or there is a restriction that no
parameters are passed to the executable, or there has to be a way of
specifying executable and parameters separately.

There is a similar driver in Subversion: a shell is used when invoking
the arbitrary, used-defined, --editor-cmd/SVN_EDITOR string so that
Subversion does not have to parse it. This is different from hooks
where a direct exec is used.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*