[ GLSA 200407-20 ] Subversion: Vulnerability in mod_authz_svn

[Joshua J. Berry]

--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200407-20
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Severity: Low
Title: Subversion: Vulnerability in mod_authz_svn
Date: July 26, 2004
Bugs: #57747
ID: 200407-20

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis
========

Users with write access to parts of a Subversion repository may bypass
read restrictions in mod_authz_svn and read any part of the repository
they wish.

Background
==========

Subversion is an advanced version control system, similar to CVS, which
supports additional functionality such as the ability to move, copy and
delete files and directories. A Subversion server may be run as an
Apache module, a standalone server (svnserve), or on-demand over ssh (a
la CVS' ":ext:" protocol). The mod_authz_svn Apache module works with
Subversion in Apache to limit access to parts of Subversion
repositories based on policy set by the administrator.

Affected packages
=================

-------------------------------------------------------------------
Package / Vulnerable / Unaffected
-------------------------------------------------------------------
1 dev-util/subversion <= 1.0.4-r1 >= 1.0.6

Description
===========

Users with write access to part of a Subversion repository may bypass
read restrictions on any part of that repository. This can be done
using an "svn copy" command to copy the portion of a repository the
user wishes to read into an area where they have write access.

Since copies are versioned, any such copy attempts will be readily
apparent.

Impact
======

This is a low-risk vulnerability. It affects only users of Subversion
who are running servers inside Apache and using mod_authz_svn.
Additionally, this vulnerability may be exploited only by users with
write access to some portion of a repository.

Workaround
==========

Keep sensitive content separated into different Subversion
repositories, or disable the Apache Subversion server and use svnserve
instead.

Resolution
==========

All Subversion users should upgrade to the latest available version:

# emerge sync

# emerge -pv ">=dev-util/subversion-1.0.6"
# emerve ">=dev-util/subversion-1.0.6"

References
==========

[ 1 ] ChangeLog for Subversion 1.0.6
http://svn.collab.net/repos/svn/tags/1.0.6/CHANGES

Availability
============

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

http://security.gentoo.org/glsa/glsa-200407-20.xml

Concerns?
=========

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.

License
=======

Copyright 2004 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/1.0

--mYCpIKhGyMATD0i+
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBBUzdaIxeYlQMsxsRAoTpAJ9AAqgcgLj/xBYo8m7+g22WnFNkigCcDyZh
8u/QON1iQqjd/c59jY7sOJg=
=8c8r
-----END PGP SIGNATURE-----

--mYCpIKhGyMATD0i+--

[Jack Repenning]

--Apple-Mail-13-989774672
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
format=flowed


On Jul 26, 2004, at 11:26 AM, Joshua J. Berry wrote:

> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Gentoo Linux Security Advisory GLSA 200407-20
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> http://security.gentoo.org/
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> Severity: Low
> Title: Subversion: Vulnerability in mod_authz_svn
> Date: July 26, 2004
> Bugs: #57747
> ID: 200407-20
>
> ========
> ...

> Workaround
> ==========
>
> Keep sensitive content separated into different Subversion
> repositories, or disable the Apache Subversion server and use svnserve
> instead.


This advice, although straight out of the Subversion announcement, is
perhaps misleading.

The problem described here only arises if you try to set up some rather
complicated permissions. Specifically, there must be a directory which
is legitimately readable by the attacker, containing things which are
not. The attacker copies the readable directory, and mod_authz_svn
permission-checks the top directory, but not all its contents (a
Subversion "copy" is something more in the line of a link or symlink: a
single new reference to the same data, not an actual visiting of all
the data "copied").

Example:
- attacker has read rights to /trunk/*, except for /trunk/hiddenstuff/*
- attacker also has _write_ rights to /tags/*
= attacker copies /trunk to /tags/peekaboo, gets (among other things)
/tags/peekaboo/hiddenstuff

The thing is: mod_authz_svn is the only authorization module available
that can express anything this complicated. If you switch to svnserve,
you lose the ability to ask for this thing in the first place. While,
yes, that means there's no bug, that's because you can no longer hide
things this way. It's not so much that the locks over there are
better, but that they sort of don't exist, or don't fit this door, or
some such metaphor.

If you can indeed live with the simpler security model of svnserve,
then you could also live with straight Apache permissions management;
they're equivalent. So there's no need to abandon Apache. And indeed,
if you can live with the simpler security model, you may simply not
bother to configure the complicated one in mod_authz_svn; there are
still cool options available to you there, and not in any of the other
places.

As a matter of fact, if you can live with the simpler security model,
you can just ignore the whole issue, because that's what you have.

And of course, if you *can't* live with the simpler model, if you
really do need this trick, then switching technologies doesn't help you
any: you want the patch.





-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835.8090

--Apple-Mail-13-989774672
Content-Transfer-Encoding: 7bit
Content-Type: application/octet-stream;
x-unix-mode=0666;
name="mime-attachment"
Content-Disposition: attachment;
filename=mime-attachment

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBBUzdaIxeYlQMsxsRAoTpAJ9AAqgcgLj/xBYo8m7+g22WnFNkigCcDyZh
8u/QON1iQqjd/c59jY7sOJg=
=8c8r
-----END PGP SIGNATURE-----

--Apple-Mail-13-989774672--