Security and shared write access to working copies

This email is my summary of an issue that has been discussed off-list.
While it's written from a Unix point of view some of it may also apply
to Windows, but I don't know enough about Windows to say for sure.

Recent changes to Subversion have allowed multiple users to share
write access to a working copy. This would usually involve group
write access, although it could also be done using non-group,
i.e. world or other, write access. The security concern is that
shared write access to a working copy could be exploited to gain read
or write access to files outside the working copy. The suggested
exploit uses Subversion's log file mechanism, and/or symbolic links in
the working copy.

The log file mechanism is used to ensure that the working copy remains
valid in the face of an interrupted, or killed command, even when
multiple changes need to be made, e.g. updating both a text-base file
and a text-base checksum entry. The mechanism works by having the
process first write a log file containing instructions and then
interpret that file and execute the instructions. A number of log
file instructions are available, including: append one file to
another, move a file, delete a file, run a three-way merge, make a
file read-only, etc. A typical instruction to move a file looks like:
<mv dest=".svn/dir-props" name=".svn/tmp/dir-props"/>

The first suggested attack is for user B to be able to control the
content of a log file run by user A. One way B can do this is for B
to write a log file, leave it in a locked directory, and wait for A to
run cleanup. A more sophisticated approach would be a timing attack
that allowed B to modify a log file created by user A during a command
such as update or commit. I don't know how practical such a timing
attack would be.

The second suggested attack is for user B to exploit a normal log file
by arranging for it to refer to files outside the working copy. If
user B can anticipate the log file instructions then user B may be
able to construct a symbolic link such that a name within the working
copy refers to an file outside the working copy.

How could such attacks be defeated? A number of defences have been
suggested, it's not clear how practical or successful these would be.

The first approach is to avoid running log files written by the
attacker. The basic idea is that Subversion should create log files
that are only writeable by the current user, and then check that the
current user owns the file and that no other write access is allowed
before interpreting the commands. This is tricky because the log
files need to retain all the read access as permitted by the umask,
but write access needs to denied from the moment the file is created.
Not only is it difficult to make permissions/umask stuff thread safe,
it has the added drawback that only the user who created the log file
can run cleanup. If some other user wanted to run cleanup the log
file must be moved and copied back (hence the need for read access
even when write access is denied) and that's a race since at one stage
there will be no log file meaning cleanup could simply remove the
locks.

The second approach is to detect malicious paths in the log file.
While it is relatively simple to ensure that a path refers to an item
in the working copy it is more difficult to handle symbolic links.
Detecting symbolic links is awkward, particularly if races are to be
avoided, Subversion may need to check every component of every path it
handles, and that could well have a serious effect on performance.

While parts of the above are easy to implement, just doing the easy
bits alone doesn't seem that useful. At present the advice is to
share working copy write access only with users that one trusts.
Shared read access has no such problems.

To put this problem into perspective: it's not really a problem for a
shared working copy used as in a development environment since a
shared Makefile, a shared shell script or shared source code can be
exploited just as easily as the Subversion client. It might be more
of a concern where the shared working copy is assumed to be just a
collection of files.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org