Subversion versions up to and including 1.4.3 have a bug which allows,
in certain specific scenarios, data stripped from the output of 'svn
log' due to the requesting user's lack of access priveleges to be
visible via 'svn propget', 'svn proplist', and 'svn propedit'.

Details:
========

Like most version control systems, access to versioned objects in
Subversion is determined on primarily path-based system.  Users either
do or don't have the ability to read a given path.

However, unlike many version control systems where versioned objects
maintain their own distinct version information (revision numbers,
authors, log messages, change timestamps, etc.), Subversion binds
multiple paths changed as part of a single commit operation into a
set, calls the whole thing a revision, and hangs commit metadata
(author, date, log message, etc.) off of that revision.  So, commit
metadata is shared across all the paths changed as part of a given
commit operation.

It is common for log messages to give detailed information about
changes made in the commit to which the log message is attached.  Such
information might include a mention of all the files changed, what was
changed in them, and so on.  But this causes a problem when presenting
information to readers who aren't authorized to read every path in the
repository.  Simply knowing that a given path exists may be a security
leak, even if the user can't see the contents of the data located at
that path.

So Subversion does what it reasonably can to prevent the leak of this
information, and does so via a staged revision access policy.  A
reader can be said to have one of three levels of access to a given
revision's metadata, based solely on the reader's access rights to the
paths changed or copied in that revision:

  'full access' -- Granted when the reader has access to all paths
     changed or copied in the revision, or when no paths were 
     changed in the revision at all, this access level permits
     full visibility of all revision property names and values,
     and the full changed-paths information.

  'no access' -- Granted when the reader does not have access to any
     paths changed or copied in the revision, this access level
     denies the reader access to all revision properties and all
     changed-paths information.

  'partial access' -- Granted when the reader has access to at least
     one, but not all, of the paths changed or copied in the revision,
     this access level permits visibility of the svn:date and
     svn:author revision properties and only the paths of the
     changed-paths information to which the reader has access.
 
The bug covered in this advisory causes readers who should be granted
'partial access' to a revision to instead be granted 'full access' for
certain revision-property-related query operations.  This situation
occurs when the reader

   * has access to all paths changed in the revision, but

   * does not have access to all the paths copied in the revision, and

   * is using the following subcommands (or the APIs behind them): 
     svn propget, svn proplist, svn propedit.

An example:  

If in a given revision path /public/document.txt was created as a copy
of /private/document.txt, and a reader has sufficient authorization to
read /public/document.txt but not to read /private/document.txt,
that reader should be granted partial access to the revision.  And, in
fact, 'svn log' (and the APIs behind it) will grant the proper access
level.  But the aforementioned 'svn prop*' commands fail to take copy
source paths into consideration when making a revision access level
determination -- meaning they only check the reader's access to the
copy destination (the actual path changed) -- and will grant this
reader full access.  Where 'svn log' would reveal only the author and
datestamp of the revision, 'svn prop*' would allow the reader to see
all of the revision properties, including the log message.

Severity:
=========

This is expected to be a rare scenario.  While path-based
authorization is common practice, data is not commonly copied from a
private location to a public one.  The 'svn prop*' commands only
reveal the contents of properties, not the revision's changed-paths
information.  And, of course, this bug does not permit anyone to see
file contents or directory listings that they should not.  Information
leaked via this bug is limited to the contents of revision properties
associated with revisions whose changed-path information meets the
specific criteria mentioned above.

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

Log messages and other revision properties can be modified at any
time, so if you believe your repository contains revision properties
which might reveal in this scenario information best left unrevealed,
you can change or remove (perhaps temporarily) the property values.

Recommendations:
================


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

CVE-2007-2448: