Bug 1205140 (CVE-2015-0251) - CVE-2015-0251 subversion: (mod_dav_svn) spoofing svn:author property values for new revisions
Summary: CVE-2015-0251 subversion: (mod_dav_svn) spoofing svn:author property values f...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2015-0251
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1207725 1242733 1250012 1250021 1252262
Blocks: 1205182
TreeView+ depends on / blocked
 
Reported: 2015-03-24 10:18 UTC by Vasyl Kaigorodov
Modified: 2023-05-12 08:10 UTC (History)
6 users (show)

Fixed In Version: Subversion 1.7.20, Subversion 1.8.13
Doc Type: Bug Fix
Doc Text:
It was found that the mod_dav_svn module did not properly validate the svn:author property of certain requests. An attacker able to create new revisions could use this flaw to spoof the svn:author property.
Clone Of:
Environment:
Last Closed: 2015-10-27 10:35:59 UTC
Embargoed:


Attachments (Terms of Use)
Patch against 1.7.19 (2.42 KB, patch)
2015-03-24 12:03 UTC, Vasyl Kaigorodov
no flags Details | Diff
Patch against 1.8.11 (2.41 KB, text/plain)
2015-03-24 12:04 UTC, Vasyl Kaigorodov
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:1633 0 normal SHIPPED_LIVE Moderate: subversion security update 2015-08-17 12:10:30 UTC
Red Hat Product Errata RHSA-2015:1742 0 normal SHIPPED_LIVE Moderate: subversion security update 2015-09-08 17:09:57 UTC

Description Vasyl Kaigorodov 2015-03-24 10:18:46 UTC
Summary:
========

  Subversion's mod_dav_svn server allows setting arbitrary svn:author
  property values when committing new revisions.  This can be accomplished
  using a specially crafted sequence of requests.  An evil-doer can fake
  svn:author values on his commits.  However, as authorization rules are
  applied to the evil-doer's true username, forged svn:author values can
  only happen on commits that touch the paths the evil-doer has write
  access to.

  Doing so does not grant any additional access and does not circumvent the
  standard Apache authentication or authorization mechanisms.  Still, an
  ability to spoof svn:author property values can impact data integrity in
  environments that rely on these values.

  There are no known instances of the problem being exploited in the wild,
  but an exploit has been tested.

Details:
========

  The Subversion http://-based protocol used for communicating with
  a Subversion mod_dav_svn server has two versions, v1 and v2.  The v2
  protocol was added in Subversion 1.7.0, but the server allows using both
  protocol versions for compatibility reasons.  When a commit happens, the
  client sends a sequence of requests (POST, PUT, MERGE, etc.) that depend
  on the negotiated protocol version.

  Usually, a server uses the name of the authenticated user as the svn:author
  value for a new revision.  However, with a specially handcrafted v1 request
  sequence, a client can instruct the server to use the svn:author property
  that she/he provided.  In this case, the server will use an arbitrary value
  coming from the client instead of the svn:author value originating from
  the authentication mechanism.

Severity:
=========

  CVSSv2 Base Score: 3.5
  CVSSv2 Base Vector: AV:N/AC:M/Au:S/C:N/I:P/A:N

  We consider this to be a medium risk vulnerability.

  An attacker needs to have commit access to the repository to exploit the
  vulnerability.  The ability to spoof svn:author property values can impact
  data integrity in environments that expect the values to denote the actual
  commit author.  The real ID of the author could still be determined using
  server access logs.  However, it is also possible that a spoofed change
  could go in unnoticed.

  Subversion's repository hooks might see the real ID of the author or the
  forged value, depending on the hook type and the hook contents:

  - A start-commit hook will see the real username in the USER argument
  - A start-commit hook will see the real username when performing
    'svnlook propget --revprop -t TXN_NAME'
  - A pre-commit hook will see the forged username when performing
    'svnlook propget --revprop -t TXN_NAME'
  - A post-commit hook will see the forged username when performing
    'svnlook propget --revprop -r REV'

  Unfortunately, no special configuration is required and all mod_dav_svn
  servers are vulnerable.

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

  No workaround is available.

Acknowledgements:

Red Hat would like to thank the Apache Software Foundation for reporting this issue. Upstream acknowledges Evgeny Kotkov of VisualSVN as the original reporter.

Comment 1 Vasyl Kaigorodov 2015-03-24 12:03:42 UTC
Created attachment 1005810 [details]
Patch against 1.7.19

Comment 2 Vasyl Kaigorodov 2015-03-24 12:04:16 UTC
Created attachment 1005811 [details]
Patch against 1.8.11

Comment 4 Martin Prpič 2015-03-31 14:50:32 UTC
External References:

https://subversion.apache.org/security/CVE-2015-0251-advisory.txt

Comment 5 Martin Prpič 2015-03-31 14:51:14 UTC
Created subversion tracking bugs for this issue:

Affects: fedora-all [bug 1207725]

Comment 9 Fedora Update System 2015-07-29 01:53:55 UTC
subversion-1.8.13-7.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 15 errata-xmlrpc 2015-08-17 08:11:02 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2015:1633 https://rhn.redhat.com/errata/RHSA-2015-1633.html

Comment 16 errata-xmlrpc 2015-09-08 13:10:19 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2015:1742 https://rhn.redhat.com/errata/RHSA-2015-1742.html

Comment 17 Siddharth Sharma 2015-10-27 10:35:59 UTC
Statement:

Red Hat Enterprise Linux 5 is now in Production 3 Phase of the support and maintenance life cycle. This has been rated as having Low security impact and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.


Note You need to log in before you can comment on or make changes to this bug.