Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 65085 - dev-util/subversion 1.0.8 Released
Summary: dev-util/subversion 1.0.8 Released
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High minor (vote)
Assignee: Gentoo Security
URL: http://subversion.tigris.org/servlets...
Whiteboard: B4 [glsa] jaervosz
Keywords:
: 65120 65121 65122 65124 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-09-23 06:19 UTC by David Newman
Modified: 2011-10-30 22:41 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Newman 2004-09-23 06:19:43 UTC
Subversion 1.0.8 was released on September 22nd.

Reproducible: Didn't try
Steps to Reproduce:
Comment 1 Paul de Vrieze (RETIRED) gentoo-dev 2004-09-23 12:53:21 UTC
I'll let this bug double up as tracker for the stabilization as it is a security update
Comment 2 Sune Kloppenborg Jeppesen gentoo-dev 2004-09-23 13:25:46 UTC
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.
Comment 3 Sune Kloppenborg Jeppesen gentoo-dev 2004-09-23 13:28:00 UTC
*** Bug 65120 has been marked as a duplicate of this bug. ***
Comment 4 Sune Kloppenborg Jeppesen gentoo-dev 2004-09-23 13:28:31 UTC
*** Bug 65121 has been marked as a duplicate of this bug. ***
Comment 5 Sune Kloppenborg Jeppesen gentoo-dev 2004-09-23 13:28:38 UTC
*** Bug 65122 has been marked as a duplicate of this bug. ***
Comment 6 Sune Kloppenborg Jeppesen gentoo-dev 2004-09-23 13:28:50 UTC
*** Bug 65124 has been marked as a duplicate of this bug. ***
Comment 7 Sune Kloppenborg Jeppesen gentoo-dev 2004-09-23 13:29:41 UTC
Arches please mark subversion-1.0.8 stable

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

Target keywords:
KEYWORDS="x86 sparc ppc amd64 alpha hppa"
Comment 8 Luke Macken (RETIRED) gentoo-dev 2004-09-23 21:40:38 UTC
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.
Comment 9 Jochen Maes (RETIRED) gentoo-dev 2004-09-24 01:04:41 UTC
stable on ppc
Comment 10 Gustavo Zacarias (RETIRED) gentoo-dev 2004-09-24 08:36:36 UTC
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?
Comment 11 Paul de Vrieze (RETIRED) gentoo-dev 2004-09-24 12:06:46 UTC
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.
Comment 12 Jason Wever (RETIRED) gentoo-dev 2004-09-24 15:42:36 UTC
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.
Comment 13 SpanKY gentoo-dev 2004-09-24 19:24:26 UTC
hppa stable
Comment 14 SpanKY gentoo-dev 2004-09-24 19:39:27 UTC
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 ?
Comment 15 Thierry Carrez (RETIRED) gentoo-dev 2004-09-25 01:03:09 UTC
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.
Comment 16 SpanKY gentoo-dev 2004-09-25 01:22:07 UTC
ok, well src_test() passed for me on amd64/hppa 
Comment 17 Paul de Vrieze (RETIRED) gentoo-dev 2004-09-25 03:15:32 UTC
Gustavo, did you compile with berkdb support included? It might very well be that the tests only work with berkdb enabled.
Comment 18 Gustavo Zacarias (RETIRED) gentoo-dev 2004-09-25 05:22:46 UTC
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.
Comment 19 Jason Wever (RETIRED) gentoo-dev 2004-09-25 05:27:55 UTC
Gustavoz:  I say for now we go for it.  We can always open up a bug afterwards and work on the issue.
Comment 20 Gustavo Zacarias (RETIRED) gentoo-dev 2004-09-25 05:44:29 UTC
Stable on sparc.
Comment 21 Sune Kloppenborg Jeppesen gentoo-dev 2004-09-26 04:52:59 UTC
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.
Comment 22 Thierry Carrez (RETIRED) gentoo-dev 2004-09-26 13:38:00 UTC
Would vote no GLSA.
Comment 23 Paul de Vrieze (RETIRED) gentoo-dev 2004-09-27 01:10:31 UTC
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.
Comment 24 Bryan Østergaard (RETIRED) gentoo-dev 2004-09-27 02:24:06 UTC
Stable on alpha.
Comment 25 Sune Kloppenborg Jeppesen gentoo-dev 2004-09-27 03:14:46 UTC
GLSA will be released. Security please draft.
Comment 26 Sune Kloppenborg Jeppesen gentoo-dev 2004-09-29 13:22:05 UTC
GLSA 200409-35