This has been assigned CVE-2013-1849
On Thu, Mar 7, 2013 at 12:20 PM, Ben Reser <ben_at_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.
Received on 2013-03-12 19:41:12 CET