It was reported that the Subversion svnserve daemon is vulnerable to a symlink attack when the --pid-file argument is passed to it. If the PID file were written in a directory that is writable by an unprivileged user, that user could create a symlink to a file that would be overwritten with the privilges of the svnserve daemon (typically root). As well, because the initscripts read the contents of the file to determine which process to kill on service shutdown, if it were symlinked to a file writable by the local user, they could replace the contents of the file with another application's pid, which would cause a different application to be killed when the svnserve initscript is called to stop the service. By default, Red Hat Enterprise Linux and Fedora call svnserve with '--pid-file=/run/svnserve/svnserve.pid' (Fedora) or '--pid-file=/var/run/svnserve.pid' (Red Hat Enterprise Linux). These directories are not writable by unprivileged users. Acknowledgements: Red Hat would like to thank Ben Reser of the Apache Subversion project for reporting this issue. Upstream acknowledges Daniel Shahaf of elego Software Solutions GmbH as the original issue reporter.
This issue is embargoed until 29 August 2013 17:00 UTC.
Created attachment 789398 [details] upstream patch to fix CVE-2013-4277 in subversion 1.8.x
External References: http://subversion.apache.org/security/CVE-2013-4277-advisory.txt
Created subversion tracking bugs for this issue: Affects: fedora-all [bug 1003070]
subversion-1.7.13-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
As mentioned in comment #0, Red Hat and Fedora versions of subversion package are not vulnerable to this issue, because they create the pid files at a secure location (not writable by unprivileged users). The only way this flaw could be exploited was if a root user changed the default location of the creation of pid files via "/etc/sysconfig/svnserve" or "/etc/init.d/svnserve" to a directory writable by unprivileged users. Therefore, The Red Hat Security Response Team, does not consider this issue as a security flaw.
Statement: The Red Hat Security Response Team does not consider this issue to be a security flaw. For technical details please refer to https://bugzilla.redhat.com/show_bug.cgi?id=1000202#c10