Subversion 1.0.8 released. *SECURITY FIX*

Ben Reser <[email protected]> Wed, 22 Sep 2004 19:04:57 -0700
Newsgroups gmane.mail.eyebrowse.devel,gmane.comp.version-control.subversion.announce
Message-ID <20040923020457.GM2858__38987.4963243075$1095953730$gmane$org@synapse.brain.org>
Subversion 1.0.8 is ready. Grab it from:

  http://subversion.tigris.org/tarballs/subversion-1.0.8.tar.gz
  http://subversion.tigris.org/tarballs/subversion-1.0.8.tar.bz2 
  http://subversion.tigris.org/tarballs/subversion-1.0.8.zip

The MD5 checksums are:

  40b5b5edd4e0daec802661cd64d562e4  subversion-1.0.8.tar.gz
  b2378b7d9d00653249877531a61ef1db  subversion-1.0.8.tar.bz2
  9fec445c8ffdad08cd89515c62de9c4d  subversion-1.0.8.zip

PGP Signatures are available at:
   http://subversion.tigris.org/tarballs/subversion-1.0.8.tar.gz.asc
   http://subversion.tigris.org/tarballs/subversion-1.0.8.tar.bz2.asc
   http://subversion.tigris.org/tarballs/subversion-1.0.8.zip.asc

PGP Signatures will be made by the following person(s) for this release:
   Ben Reser [1024D/641E358B] with fingerprint:
   42F5 91FD E577 F545 FB40  8F6B 7241 856B 641E 358B


This release fixes a security flaw.  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.

Thanks,
-The Subversion Team 

--------------------8-<-------cut-here---------8-<-----------------------

 User-visible-changes:
 * fixed: mod_authz_svn path and log-message metadata leaks.
          See CAN-2004-0749, and descriptive advisory at
          http://subversion.tigris.org/security/CAN-2004-0749-advisory.txt