[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: disable security hole in svn+ssh?

From: Andy Canfield <andy.canfield_at_pimco.mobi>
Date: Thu, 28 Jul 2011 21:29:34 +0700

On 07/27/2011 06:47 PM, Nico Kadel-Garcia wrote:
> On Wed, Jul 27, 2011 at 12:06 AM, Andy Canfield
> <andy.canfield_at_pimco.mobi> wrote:
>> I was trying to get http, svn, and svn+ssh to work.
> Dude. Pick one. Getting all three to play nicely together is destablilizing.
For me, getting any of the four to work is difficult. Here is the status
of the various protocols, in order by apparent desirability. The
problems are in parentheses.

Server: Test Production
Network: on LAN on Internet
               -------- -------------------
1. HTTPS: (config) (config)
2. HTTP: OK (software mismatch)
3. SVN: OK (port not forwarded)
4. SVN+SSH: (security) (security)

Now you see why I'm trying to get any of them working. Every alternative
has a problem. I can't get HTTPS to work at all. HTTP on the production
server fails due to a software mismatch which we may not be able to fix;
the distro from Apple seems to be bad. SVN requires our ISP to change
our Router settings. SVN+SSH authentication worksfor me without
authorization checking.

>> Â Â Â svn infohttp://athol/svn/subdoc
>> Authentication realm:<http://athol:80> Athol Subversion Repository
>> Password for 'andy':
>> Path: subdoc
>> URL:http://athol/svn/subdoc
>> Repository Root:http://athol/svn/subdoc
>> Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138
>> Revision: 4
>> Node Kind: directory
>> Last Changed Author: andy
>> Last Changed Rev: 4
>> Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011)
> Hold it right there. You're providing password based repository access
> via HTTP, not HTTPS? Please rethink this unless you *want* the
> passwords for this repository to be quite insecure and sniffable,
> especially if you're using normal user login passwords.
If HTTP sends passwords in as plain text then yes, HTTPS is better. But
I can't get HTTPS to work at all. I get the impression from googling
that HTTPS requires a certificate, and I don't have a certificate. If I
could generate my own certificate, we could tell our developers "Accept
this certificate the first time you see it, and after that it will work
every time."

> Also note. For HTTP access from Linux and UNIX systems, the default
> behavior is to store the password, in cleartext, in
> $HOME/.subversioon/. *That* is a longstanding security issue that I've
> been ranting about for *years*. Subversion 1.6.x, very reasonably, now
> asks for permission before doing that, But if you're using the same
> password authenticatoin for svn+ssh://,http://,https://, and svn://
> based access, you're now writing your password in plain text. locally.
> svn+ssh:// doesn't recored that plain text password,http:// and
> htps:// do.
>> Â Â Â svn info svn://athol/subdoc
>> Authentication realm:<svn://athol:3690> Subversion svnserve
>> Password for 'andy':
>> Path: subdoc
>> URL: svn://athol/subdoc
>> Repository Root: svn://athol/subdoc
>> Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138
>> Revision: 4
>> Node Kind: directory
>> Last Changed Author: andy
>> Last Changed Rev: 4
>> Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011)
> Again. Unencrypted passwords, unless you're using something like SASL.
> Do not use this for normal user passwords.
Unencrypted passwords stored on the server. We can make the file
accessable only by the Apache user. Not ideal, but not bad. If the
hacker roots the server we've got no security anyway.
>> Â Â Â svn info svn+ssh://athol/data/svn/subdoc
>> The authenticity of host 'athol (' can't be established.
>> ECDSA key fingerprint is 4a:9d:73:24:94:24:15:a8:08:0c:cd:59:72:d4:3a:d7.
>> Are you sure you want to continue connecting (yes/no)? yes
>> kids_at_athol's password:
>> Path: subdoc
>> URL: svn+ssh://athol/data/svn/subdoc
>> Repository Root: svn+ssh://athol/data/svn/subdoc
>> Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138
>> Revision: 4
>> Node Kind: directory
>> Last Changed Author: andy
>> Last Changed Rev: 4
>> Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011)
>> What's 'worse' about it? Well, 'kids' is a valid user name on the server;
> Which it need not be. The gudebook does not make this clear enough:
> For users who have normal shell access *anyway*, many sites do use
> this approach and simply set the repository to be manged with group
> access to designated users. But in the "we don't want people to need
> shell access to use svn+ssh", you need to set up something like an SSH
> key on a shared account with forced commands, typically with this kind
> of URL.
> svn+ssh://svn@sitename/svn/reponame/
Near as I can tell svn+ssh uses ssh for authentication but it does not
seem to do any authorization at all. At that point anybody with an SSH
login can do anything; there is no authorization phase for svn+ssh. I am
trying to fix that, perhaps using an authz file in every repository, but
haven't got it working yet.

> That "svn" user can be set to have no valid shell, with its shell set
> to something like "/sbin/nologin". This is actually quite common for
> system services to have no valid shell. This is how the "apache" or
> "www-data" user is usually set up.
But that would prevent login using ssh, which I don't want. I can tell
the sysadmin "we need an SSH login for Charlie so he can use
Subversion", but I cannot say "You have to cut the SSH login for Marilyn
so she can't use Subversion".

>> 'kids' can ssh into the server. But 'kids' has no authorization to access
>> any Subversion repository in any way. To me this means that svn+ssh is a
>> GIGANTIC security hole.
> See above. That "forced command" bit is really important for systems
> where you don't want subverson authorized users to have shell access.
> I've actually had extensive battles about this sort of thing with
> sites where the internal policy was "as long as they're in, we already
> trust them with shell on such servers".
> This is actually tied to a subtler, longstanding deficit in
> Subversion: a dedicated shell for an "svn" user. I've attempted myself
> to integrate this sort of thing into the "rssh" toolkit used for rsync
> access.
I am working on a changed arrangement, where the SVNParentPath is
"/Subversion" and in this is a subdirectory named "conf". Inside config
are files "server.conf", "passwd", "htpasswd", and "authz". These files
are used for authentication whenever Subversion needs to do it; they
should be used for authrization in all cases. Then
/Subversion/repository/conf is a symoblic link to /Subversion/conf.
Maybe it will work; maybe not.
>> Consider these commands:
>> Â Â Â sshkids_at_example.com
>> Â Â Â rm -rf /data/svn/subdoc
>> They do nothing; user 'kids' has no right to see anything inside the
>> /data/svn directory, which is owned by www-data and readable (and writable)
>> only by that user.
> Only if you're using the "shared account" access method to svn+ssh,
> where the URL includes the username or otherwise successfully forces
> access to have that username. If you're doing the unfortunately common
> approach of normal user accounts with shared group access to the
> Subversion repository, you can scrub the database clean. It's one of
> the reasons I *hate* that normal user account method. The same sort of
> thing occurs in CVS repositories: it allows a considerable amount of
> relocation and behind the scenes editing of Subversion repositories,
> and is one of the ways to flush oversized binaries, such as DVD
> images, that soomeone might accidentally incorporate. It's also a way
> to *completely* screw up a repo for someone else, and one of the
> strongest reasons to have a backup system that uses 'svnsync' and
> talks to another location.
> Yeah. This is why you use a shared, SSH key accessed account without
> normal login shell access, but with for forced "commands" associated
> with the SSH keys. It's awkward and means you need key management, and
> it is untenable to use for single-sign-on tools such as Kerberos with
> GSSAPI. But it does seem to be *exactly* what Sourceforge uses, and
> has for years, for both CVS and Subversion repository access. Their
> git repository access can use the built in git shell tool more easily,
> and I'm sure it does.
>> But consider these commands:
>> Â Â Â mkdir t
>> Â Â Â cd t
>> Â Â Â svn checkout svn+ssh://example.com/data/svn/subdoc
>> Â Â Â svn delete *
>> Â Â Â svn commit
>> These will post a revision deleting everything in the repository. And this
>> second set of commands relies only on 'kids' being able to log in to the
>> server; they need not have any permission to do anything in Subversion!
> First: that command won't do what you think. You'll wind up with
> t/subdoc, and the "svn delete" command will be in the "t" directory,
> and the "svn delete *" will be run from a non-subversion parent
> directory. But that's not the problem.
I think it does do what I think it does.
<== The current directory is /a/b/c
     mkdir t <== create /a/b/c/t
     cd t <== The current directory is /a/b/c/t
     svn checkout svn+ssh://example.com/data/svn/subdoc <== /a/b/c/t is
a working copy
     svn delete * <== delete everything in this working copy on next commit
     svn commit <== New revision, deletes everything
I might also do:
     cd .. <== The current directory is now /a/b/c
     rm -rf t <== wipe out my working copy in t

> The problem you're describing here is that in a normal, casually
> configured setup, it is *designed* to allow write access to the whole
> repository, and you can do something like any of these:
> svn deletehttp://athol/svn/subdoc/*
> svn delete svn://athol/subdoc/*
> svn delete svn+ssh://athol/data/svn/subdoc/*
http: requires Apache authentication and uses dav_mod_svn authentication
and authorization . svn: uses the svnserve daemon which was run with a
"--config-file=..." parameter for authentication and authorization.
svn+ssh uses SSL for authentication but because SSL is running a fresh
copy of svnserve we have no chance to tell svnserve where to look for
the authorizations.
> You don't need to check out anything to do moves and deletions, and
> this is normal. But all users in a casual setup have full access to
> delete *ANYTHING*, and to re-arrange it at whim. This is why the
> access control hooks are designed to allow people to say "OK, only the
> admins are allwed to write to trunk" or "only admins are allowed to
> write tags" or "anyone can create or flush branches, anyone can create
> tags, but no one can *delete* or move tags", and all the other
> options.
But users that Subversion has never heard of should not have that power.
My testing of svn+ssh indicates that once ssh authenticates a user,
svnserve does not seem to check authorization at all. That's my problem.
>> Is there any way to modify things on the server to disable the svn+ssh:
>> protocol without disabling either standard ssh or the svn: protocol?
> Turn the question around. svn+ssh:// has to be *enabled* by providing
> the shared write access to the Subversion repositories.
> Simply keep
> the repositories owned with write permissions restricted to the
> designated "www-data" or "apache" user, and rely on the authentication
> to set the user for incoming connections, and there will be no enabled
> svn+ssh:// access.
> Frankly, I think people are a lot safer with the svn+ssh:// because of
> the password handling.
I can get authentication but cannot yet get suthorization.

So there are actually four protocols that a workstation can use to
access a Subversion repository: http, https, svn:, and svn+ssh. Assuming
that I pick one, how do I turn the others off? If James Bond can access
via https, how can we prevent him from using http and blowing the
security? iIf James Bond has an ssh login account on the server, but
should not be using Subversion at all, how do we prevent him from using
svn+ssh:? How do we prevent him from logging in and using file:? How do
we prevent him from logging in and running svnadmin?
Received on 2011-07-28 16:30:18 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.