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-07 21:21:12 CET