On Fri, Sep 26, 2014 at 6:59 PM, Vincent Lefevre <vincent-svn_at_vinc17.net> wrote:
> On 2014-09-24 19:28:51 +0300, Stefan Sperling wrote:
>> From what I understand after reading about the problem briefly:
>>
>> In an svn+ssh setup svn clients run 'svnserve -t' by default.
>> But there is no reason this could not be changed to '/bin/bash' by
>> an attacker.
>>
>> Note that forcing a command in the authorized_keys file will *not*
>> work around the problem: http://seclists.org/oss-sec/2014/q3/651
>
> 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)?
>
>> It should be possible to mitigate this attack vector by having
>> svnserve run in an environment that doesn't have bash available,
>> either with no bash binary at all on the system, or within a chroot.
>
> The main bug would be that OpenSSH might be able to start bash while
> the user has never allowed it.
I've not seen the public attention to svn+ssh access that I've seen to
SSH based git access, for a stack of reasons. But yes, it could allow
access, and allow write access as the owner of the Subversion
repository. This is especially dangerous in shared environments where
the maintainer has not segregated write access the "pre-script" and
"post-script" tools from write access to the repository itself. And
even with such security, the entire source code database could be
replaced, or deleted, or have locked tags modified.
It's a very serious risk to canonical upstream source code repositories.
Received on 2014-09-27 17:24:17 CEST