Bugzilla Bug 65085

Subversion 1.0.8 was released on September 22nd.

Reproducible: Didn't try
Steps to Reproduce:

I'll let this bug double up as tracker for the stabilization as it is a
security update

Reassigning to security.

Summary:
=======

mod_authz_svn, the Apache httpd module which does path-based
authorization on Subversion repositories, is not correctly protecting
all metadata on unreadable paths.

This metadata leakage affects the mod_authz_svn module in all released
versions of Subversion (through 1.0.7), as well as the 1.1-rc1, -rc2
and -rc3 release candidates.  The leakage is fixed in the 1.0.8 and
1.1-rc4 release, as well as the upcoming 1.1 final release.


Details:
=======

If a Subversion commit affects paths that an administrator has marked
"unreadable" using mod_authz_svn, then

   - "svn log -v" will list the existence of the unreadable paths;
   - "svn log -v" will show the commit's log message, which might be
                  considered sensitive metadata in some situations;
   - "svn propget" is also able to fetch the log message of any commit;
   - "svn blame" and other commands that follow renames are able to
                  acknowledge the existence of earlier versions of
                  files that exist at unreadable locations.

Severity:
========

Mild-to-medium severity, depending on your situation.

This security issue is not about revealing the contents of protected
files: it only reveals metadata about protected areas such as paths
and log messages.  This may or may not be important to your
organization, depending on how you're using path-based authorization,
and the sensitivity of the metadata.

(Exception: in the case of "svn blame", and only in svn 1.1-rc2 and
-rc3, it's possible that older unreadable versions of a file are being
transported from server to client; the contents aren't displayed, but
the data is still traveling over the network.)

These issues only affects users of mod_authz_svn, not people using
native httpd.conf directives (such as <Limit> or <LimitExcept>)
directives to limit general readability on whole repositories.


Workarounds:
===========

* Use mod_authz_svn to restrict writes only, not reads.

* Break unreadable areas into separate repositories, and use native
  apache httpd.conf directives to make them unreadable.


References:
==========

  CAN-2004-0749: mod_authz_svn fails to protect metadata

Recommendation:
==============

We recommend an upgrade to 1.0.8 or 1.1.0-rc4.

Security fix for 1.0.  Common changes shared by all the different
patches.  Apply this patch first.

* mod_dav_svn/dav_svn.h
  (dav_svn_authz_read, dav_svn_authz_baton): new library-level
      declarations of things that were formerly static.

* mod_dav_svn/update.c
  (authz_read_baton):  remove local declaration.
  (dav_svn_authz_read):  new name of formerly static 'authz_read'.
  (dav_svn__update_report):  update caller to use new symbol names.

*** Bug 65120 has been marked as a duplicate of this bug. ***

*** Bug 65121 has been marked as a duplicate of this bug. ***

*** Bug 65122 has been marked as a duplicate of this bug. ***

*** Bug 65124 has been marked as a duplicate of this bug. ***

Arches please mark subversion-1.0.8 stable

KEYWORDS="x86 ~sparc ~ppc ~amd64 ~alpha ~hppa"

Target keywords:
KEYWORDS="x86 sparc ppc amd64 alpha hppa"

the subversion release candidate has been bumped to rc4 (bug #65140) to fix
this security issue as well.  no need to mark stable since it was unstable to
begin with.

stable on ppc

I'm getting a failed test with FEATURES="maketest"...

At least one test FAILED, checking /var/tmp/portage/subversion-1.0.8/work/subversion-1.0.8/tests.log
FAIL:  prop_tests.py 11: set, get, and delete a revprop change

CMD: svnadmin "create" "repositories/prop_tests-11" "--bdb-txn-nosync" <TIME = 1.485582>
CMD: svnadmin dump "local_tmp/repos" | svnadmin load "repositories/prop_tests-11" <TIME = 0.006130>
CMD: svn "co" "--username" "jrandom" "--password" "rayjandom" "file:///var/tmp/portage/subversion-1.0.8/work/subversion-1.0.8/subversion/tests/clients/cmdline/repositories/prop_tests-11" "working_copies/prop_tests-11" "--config-dir" "/var/tmp/portage/subversion-1.0.8/work/subversion-1.0.8/subversion/tests/clients/cmdline/local_tmp/config" <TIME = 5.417888>
CMD: svn "propset" "--revprop" "-r" "0" "cash-sound" "cha-ching!" "working_copies/prop_tests-11" "--config-dir" "/var/tmp/portage/subversion-1.0.8/work/subversion-1.0.8/subversion/tests/clients/cmdline/local_tmp/config" <TIME = 0.849097>
EXPECTED STDERR:
ACTUAL STDERR:
svn: 'pre-revprop-change' hook failed with error output:

EXCEPTION: SVNLineUnequal
FAIL:  prop_tests.py 11: set, get, and delete a revprop change

comments? ideas?

While I never tried the tests before they run correctly for me. Gustavo, could
you give some information on your architecture? You might also want to open
another bug, this is for tracking the security status.

Paul,

While yes this is a security bug, if the ebuild that fixes the security bug can't build then (imo at least) the problem should be reported here.  Or at the very least if a new bug is required, this bug should then be made dependent on the new bug.

Of course if there is somewhere that dictates policy on the above, feel free to slap me around with it's location.

hppa stable

i lied about hppa

what's the deal here ? are we supposed to be testing 1.0.8 or 1.1.0_rc4 ?
the 1.1.0_rc's are in package.mask ... but i thought 1.0.8 had a security flaw as well ?

This vulnerability is fixed in both 1.0.8 and 1.1.0_rc4. Since the latter is
package.masked (and will probably remain so until 1.1.0 release), we need 1.0.8
to be stable.

Gustavo / Jason :
Yes, you're right to report the blocker here, if it indeed is a regression. But
if maketest didn't succeed with version 1.0.6 either, then this bug shouldn't
block the security stable keyword. Could you please double-check that it used
to succeed with 1.0.6 and with 1.0.8 it doesn't ? In all cases it's probably
better to track it using another bug.

ok, well src_test() passed for me on amd64/hppa 

Gustavo, did you compile with berkdb support included? It might very well be
that the tests only work with berkdb enabled.

Koon: Yes, the tests fail at the exact same point on 1.0.6, i was talking about
that reasoning with Weeve last night.
Paul: I always test with everything enabled, so yes.
Weeve: Should we apply? I guess it's safe considering 1.0.6 fails the tests the
same way and we are the last blocker.

Gustavoz:  I say for now we go for it.  We can always open up a bug afterwards
and work on the issue.

Stable on sparc.

Sorry forgot to CC Alpha.

Please test and mark 1.0.8 stable.

All supported arches have marked stable. Security please vote on GLSA publication.

Would vote no GLSA.

While the issue is a minor issue (lowest class, where private information can
be disclosed in a non-standard environment) I still feel that the GLSA must at
least be added to the repository (for glsa-check). I'm not in the security team
but as maintainer I feel that a GLSA should be published. It is up to the users
to assess the seriousness of the issue.

Stable on alpha.

GLSA will be released. Security please draft.

GLSA 200409-35