[35883] in bugtraq
Re: [ GLSA 200407-20 ] Subversion: Vulnerability in mod_authz_svn
daemon@ATHENA.MIT.EDU (Jack Repenning)
Thu Jul 29 05:41:28 2004
In-Reply-To: <20040726182637.GA8663@deneb.condordes.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/mixed; boundary=Apple-Mail-13-989774672
Message-Id: <86861328-E019-11D8-A67B-000A956E2170@collab.net>
Cc: full-disclosure@lists.netsys.com, gentoo-announce@lists.gentoo.org,
bugtraq@securityfocus.com, security-alerts@linuxsecurity.com
From: Jack Repenning <jrepenning@collab.net>
Date: Tue, 27 Jul 2004 15:08:44 -0700
To: "Joshua J. Berry" <condordes@gentoo.org>
--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--
