[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Denial of Service: PROPFIND on Activity URL

From: Ben Reser <ben_at_reser.org>
Date: Thu, 4 Apr 2013 14:38:56 -0700

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 <ben_at_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 <ben_at_reser.org> wrote:
>> 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-04-04 23:39:37 CEST

This is an archived mail posted to the Subversion Dev mailing list.