<<< Date Index >>>     <<< Thread Index >>>

Re: [ GLSA 200407-20 ] Subversion: Vulnerability in mod_authz_svn




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