The fix for this issue is included in the 1.6.21 and 1.7.9 versions of Subversion.
Our advisory for this issue is public and published here: http://subversion.apache.org/security/CVE-2013-1849-advisory.txt On Thu, Mar 28, 2013 at 9:48 PM, Ben Reser <b...@reser.org> wrote: > Fix for this is included in the 1.6.21 and 1.7.9 tarballs up for testing. > > I've checked that they aren't vulnerable to the this issue. I'd > welcome others doing the same. > > Source packages here: > https://dist.apache.org/repos/dist/dev/subversion/ > > On Tue, Mar 12, 2013 at 11:40 AM, Ben Reser <b...@reser.org> wrote: >> This has been assigned CVE-2013-1849 >> >> On Thu, Mar 7, 2013 at 12:20 PM, Ben Reser <b...@reser.org> wrote: >>> A couple days ago this email was posted on the full disclosure mailing list: >>> http://seclists.org/fulldisclosure/2013/Mar/56 >>> >>> The basic guts of the post is this: >>> [[[ >>> Basically it requires >= 2 requests to crash apache child process (in >>> mod_dav_svn / libsvn_fs). >>> -- cut -- >>> 1. MKACTIVITY /egg/!svn/act/foo HTTP/1.1 >>> 2. PROPFIND /egg/!svn/act/foo HTTP/1.1 (sigsegv) >>> -- cut -- >>> ]]] >>> >>> Some background: When an SVN client wants to commit a change to a >>> Subversion repository it must create a transaction to send the changes >>> to before it finally requests that those changes be merged to form a >>> revision. Prior to our HTTPv2 protocol changes (added in Subversion >>> 1.7) this meant creating an activity URL with MKACTIVITY. MKACTIVITY >>> is still supported even in newer servers that support HTTPv2 in order >>> to support older clients. The client generated a UUID and used it as >>> the last component of the URI which it ran MKACTIVITY on (the email >>> used foo instead of a UUID). The repository then tracked these >>> activity URLs (for FSFS via files in $REPO/dav/activities.d), mapping >>> activity URLs to transaction ids used in the repository. The client >>> can issue a DELETE request to explicitly remove an activity URL and >>> some other methods implicitly remove the activity URL. However, the >>> server does not contain any code to cleanup abandoned (i.e. not >>> removed during normal actions) activity URLs, so they may build up >>> over time on a server. >>> >>> The denial of service described above issues a PROPFIND request on an >>> activity URL. There is no meaning to this request the DAV based HTTP >>> protocols that Subversion uses. There is a flaw in mod_dav_svn that >>> improperly tries to process this request instead of rejecting it and >>> results in an attempt to access invalid memory (NULL). Which results >>> in the httpd process segfaulting and dying. How bad the impact of >>> that is varies based upon the configuration of the httpd server. >>> httpd servers using a prefork MPM will simply start a new process to >>> replace the process that died. Servers using threaded MPMs may be >>> processing other requests in the same process as the process that the >>> attack causes to die. In either case there is an increased processing >>> impact of restarting a process and the cost of per process caches >>> being lost. >>> >>> A patch has been applied to trunk (http://svn.apache.org/r1453780) >>> which resolves this issue by rejecting such requests as not >>> implemented. >>> >>> Administrators that wish to protect against this without patching >>> immediately can apply the following configuration to their httpd.conf >>> file (this uses mod_rewrite so you'll need that module available): >>> [[[ >>> RewriteEngine on >>> RewriteCond %{REQUEST_METHOD} =PROPFIND >>> RewriteCond %{REQUEST_URI} /!svn/act/[^/]*/*$ >>> RewriteRule .* - [L,F] >>> ]]] >>> >>> The above configuration will not block any useful requests and can be >>> used without concern that it will break anything. It is in essence >>> doing the same thing that patch does. >>> >>> Generally MKACTIVITY is protected by an authentication requirement as >>> it is needed for commit access to the repository. However, this >>> attack does not necessarily require the attacker to execute >>> MKACTIVITY. All the attack needs is a valid activity URL. >>> >>> Activity URLs as mentioned above have UUIDs in them. Subversion >>> depends upon the APR-util library to generate the UUID and in many >>> cases APR-util depends upon an OS provided function (uuid_generate or >>> uuid_create on unix OSes and UuidCreate() on Windows). If an OS >>> provided function is not available APR-util has it's own internal >>> implementation of UUID generation code. While the various >>> implementations of UUID generation are generally unique, some of them >>> have predictable components such as the time or MAC address of a NIC >>> installed in the machine generating them. >>> >>> Activity URLs as mentioned above may not be cleaned up. So a server >>> may build up old unused activity URLs that remain valid for long >>> periods of time. Combined with the predictability of some UUIDs, >>> there is a small chance for an attacker to guess a valid activity URL >>> and as such not need to issue a MKACTIVITY against the server. >>> >>> A release for Subversion 1.6 and 1.7 will be forthcoming with the fix >>> included in it.
