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
Attachment:
mime-attachment
Description: Binary data