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

Possible security problem with svnsync?

From: Jon Foster <Jon.Foster_at_cabot.co.uk>
Date: Wed, 12 May 2010 13:07:12 +0100

Hi,

I have a repository that is partially mirrored, using svnsync and
mod_authz_svn [1]. I just realised that the administrator of the
mirror server can bypass the authz rules I've set up on the master
server. All he has to do is change the svn:sync-from-url property
on the mirror repository to be a file:// URL to the source
repository, rather than a http:// one. The correct file:// URL is
probably guessable.

Using file:// will bypass Apache's authz rules, so only filesystem
permissions are relevant. Since svnsync is being run by the
post-commit hook, it's running on the master server as the apache
user. That user has to have access to the repository files on disk,
because Apache is serving the SVN repository.

If the administrator of the mirror repository wants a full mirror of
all the secret stuff, then they also have to delete and recreate the
mirror repository, and set the revprops on r0 so that svnsync will
do a full sync the next time it is invoked.

Attack #2 (other repositories):

More generally, the administrator of the mirror repository can use
this attack to get a full mirror of ANY repository that svnsync can
access, if they know both the repository URL and UUID. In practise,
the requirement to know the UUID is likely to frustrate most attacks
that are directed against other repositories. (It does not provide
any protection whatsoever against the basic "bypass authz" attack
described earlier in this mail, because the mirror repository's
"svn:sync-from-uuid" property already contains the correct UUID).
But the repository UUID was never intended to be a security-critical
secret - it's included in plaintext in every SVN checkout, and
changing it requires everyone to fix up their working copies.

Possible workarounds:

- Don't run svnsync on the same system as the master repository,
  run it on the mirror server instead.
- Run svnsync as a different user that doesn't have access to any
  repository files.

Suggested fix:

Please can we change "svnsync sync" to allow both the source and
target URLs to be specified? That rather simple measure would block
this attack. Since svnsync is usually invoked from a script, typing
the extra URL isn't a problem.

(If only one URL is specified, then svnsync should probably behave
as it does today, for backward-compatibility. And we should
document that svnsync trusts the mirror server if you only provide
one URL).

Kind regards,

Jon Foster

[1] This is documented as supported in
http://svn.apache.org/repos/asf/subversion/trunk/notes/svnsync.txt
see "Q: How does svnsync deal with parts of the master repository
that I'm not authorized to read?"

**********************************************************************
This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd.

If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone.

Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232

Co. Registered in England number 02817269

Please contact the sender if you believe you have received this email in error.

**********************************************************************

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
Received on 2010-05-12 14:07:58 CEST

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

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