www/security/CVE-2007-2448-advisory.txt

   1 Subversion versions up to and including 1.4.3 have a bug which allows,
   2 in certain specific scenarios, data stripped from the output of 'svn
   3 log' due to the requesting user's lack of access priveleges to be
   4 visible via 'svn propget', 'svn proplist', and 'svn propedit'.
   5
   6 Details:
   7 ========
   8
   9 Like most version control systems, access to versioned objects in
  10 Subversion is determined on primarily path-based system.  Users either
  11 do or don't have the ability to read a given path.
  12
  13 However, unlike many version control systems where versioned objects
  14 maintain their own distinct version information (revision numbers,
  15 authors, log messages, change timestamps, etc.), Subversion binds
  16 multiple paths changed as part of a single commit operation into a
  17 set, calls the whole thing a revision, and hangs commit metadata
  18 (author, date, log message, etc.) off of that revision.  So, commit
  19 metadata is shared across all the paths changed as part of a given
  20 commit operation.
  21
  22 It is common for log messages to give detailed information about
  23 changes made in the commit to which the log message is attached.  Such
  24 information might include a mention of all the files changed, what was
  25 changed in them, and so on.  But this causes a problem when presenting
  26 information to readers who aren't authorized to read every path in the
  27 repository.  Simply knowing that a given path exists may be a security
  28 leak, even if the user can't see the contents of the data located at
  29 that path.
  30
  31 So Subversion does what it reasonably can to prevent the leak of this
  32 information, and does so via a staged revision access policy.  A
  33 reader can be said to have one of three levels of access to a given
  34 revision's metadata, based solely on the reader's access rights to the
  35 paths changed or copied in that revision:
  36
  37   'full access' -- Granted when the reader has access to all paths
  38      changed or copied in the revision, or when no paths were
  39      changed in the revision at all, this access level permits
  40      full visibility of all revision property names and values,
  41      and the full changed-paths information.
  42
  43   'no access' -- Granted when the reader does not have access to any
  44      paths changed or copied in the revision, this access level
  45      denies the reader access to all revision properties and all
  46      changed-paths information.
  47
  48   'partial access' -- Granted when the reader has access to at least
  49      one, but not all, of the paths changed or copied in the revision,
  50      this access level permits visibility of the svn:date and
  51      svn:author revision properties and only the paths of the
  52      changed-paths information to which the reader has access.
  53
  54 The bug covered in this advisory causes readers who should be granted
  55 'partial access' to a revision to instead be granted 'full access' for
  56 certain revision-property-related query operations.  This situation
  57 occurs when the reader
  58
  59    * has access to all paths changed in the revision, but
  60
  61    * does not have access to all the paths copied in the revision, and
  62
  63    * is using the following subcommands (or the APIs behind them):
  64      svn propget, svn proplist, svn propedit.
  65
  66 An example:
  67
  68 If in a given revision path /public/document.txt was created as a copy
  69 of /private/document.txt, and a reader has sufficient authorization to
  70 read /public/document.txt but not to read /private/document.txt,
  71 that reader should be granted partial access to the revision.  And, in
  72 fact, 'svn log' (and the APIs behind it) will grant the proper access
  73 level.  But the aforementioned 'svn prop*' commands fail to take copy
  74 source paths into consideration when making a revision access level
  75 determination -- meaning they only check the reader's access to the
  76 copy destination (the actual path changed) -- and will grant this
  77 reader full access.  Where 'svn log' would reveal only the author and
  78 datestamp of the revision, 'svn prop*' would allow the reader to see
  79 all of the revision properties, including the log message.
  80
  81 Severity:
  82 =========
  83
  84 This is expected to be a rare scenario.  While path-based
  85 authorization is common practice, data is not commonly copied from a
  86 private location to a public one.  The 'svn prop*' commands only
  87 reveal the contents of properties, not the revision's changed-paths
  88 information.  And, of course, this bug does not permit anyone to see
  89 file contents or directory listings that they should not.  Information
  90 leaked via this bug is limited to the contents of revision properties
  91 associated with revisions whose changed-path information meets the
  92 specific criteria mentioned above.
  93
  94 Workarounds:
  95 ============
  96
  97 Log messages and other revision properties can be modified at any
  98 time, so if you believe your repository contains revision properties
  99 which might reveal in this scenario information best left unrevealed,
 100 you can change or remove (perhaps temporarily) the property values.
 101
 102 Recommendations:
 103 ================
 104
 105
 106 References:
 107 ===========
 108
 109 CVE-2007-2448: