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
