full-disclosure - Re: [ GLSA 200407-20 ] Subversion: Vulnerability in mod_authz

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <86861328-E019-11D8-A67B-000A956E2170@collab.net>
From: jrepenning at collab.net (Jack Repenning)
Subject: 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mime-attachment
Type: application/octet-stream
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040727/12b06081/mime-attachment.obj