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.
