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-03-29 05:49:28 CET