[HCoop-Discuss] SVN security issues

[Karl Chen]

>>>>> On 2006-11-04 10:12 PST, Shaun Kruger writes:

    Shaun> I just looked into the hook scripts.  If they could be
    Shaun> setup with setuid bit set they would take on the
    Shaun> premissions of the user who owns the repository when
    Shaun> they run.  The next problem is how to force it to run
    Shaun> setuid the owning user or not at all.

>>>>> On 2006-11-04 13:30 PST, Paul Anderson writes:

    Paul> Would not anyone on the system be able to run those
    Paul> scripts, though?  They would need to have group
    Paul> www-data, and not be world executable.

[Subversion developers: this thread is about a system shared by
multiple users each running their own set of repositories via
mod_dav_svn with a single Apache process/user.]

The issue is not who may execute or read the hook scripts, but
that www-data is currently executing the scripts.  I agree with
Shaun that it would be a good idea to execute hook scripts as the
user owning the script and that such functionality would best be
supported within Subversion.

However, just checking for the setuid bit from a stat() call is
vulnerable to a race condition.  (An attacker would chmod u-s just
before the exec.  Yes, it's easily possible to win this race
condition, as the attacker has a user account and is invoking the
race condition.)

The Apache process should be running under www-data instead of
root so it won't (and shouldn't) be able to simply seteuid between
fork and exec.  The answer may be suEXEC or userv.  A more general
solution in Subversion would be to have a global configuration
(perhaps via Apache module configuration or SetEnv) that executes
a specified helper program to run the hook.  This helper could be
a possibly-modified suEXEC (Apache's setuid-root helper for
executing user CGI scripts), or a shell script that invokes sudo
or userv.  The only change to Subversion would be to insert one
string to the child argv.

-- 
Karl 2006-11-06 00:41