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

Re: svn commit: r1362434 - in /subversion/trunk: configure.ac subversion/include/svn_fs.h subversion/libsvn_fs/fs-loader.c

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Tue, 17 Jul 2012 17:38:28 +0400

On Tue, Jul 17, 2012 at 5:21 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Ivan Zhakov <ivan_at_visualsvn.com> writes:
>> On Tue, Jul 17, 2012 at 2:14 PM, Philip Martin
>> <philip.martin_at_wandisco.com> wrote:
>>> philip_at_apache.org writes:
>>> > Author: philip
>>> > Date: Tue Jul 17 10:12:20 2012
>>> > New Revision: 1362434
>>> >
>>> > URL: http://svn.apache.org/viewvc?rev=1362434&view=rev
>>> > Log:
>>> > Allow third party FS modules to be loaded when configured
>>> > with --enable-runtime-module-search.
>>> Until now anyone wanting to write an FS module had a problem: only
>>> modules known to the Subversion project could be loaded and used.
>>> That means that anyone wanting to write their own module had to get a
>>> patch for their module name into the core Subversion code. Or write
>>> their own loader/server.
>>> I don't think there is any security risk here: I need to write to the
>>> repository fs-type file to get a malicious module to load and if I can
>>> do that it would be far easier to use one of the hook scripts.
>> It still possible security issue here. Just image that repository is
>> stored on network share or something. Someone tweaked fs-type and put
>> fake .dll in repository folder. Then another user accesses this
>> repository and gets this dll loaded on his behalf!
> To get a DSO loaded it has to go into the library search path.
Problem that on Windows current directory is also library search path [1].

> If the victim has a world writeable location in the search path the attacker
> could replace any DSO.
The attacker cannot replace any DSO, because current directory has
lower priority than other locations. So in typical scenarios user is
not vulnerable, because DSO is found in other location.

So for security reason we should load DSO using absolute path at least
on Windows.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx#standard_search_order_for_desktop_applications

>> To prevent such issues we should valdiate fs-type to be only file name
>> with only alphanumeric characters. No dots, spaces or slashes. We also
>> should only load DSO module from directory where Subversion installed
>> for better protection.
> That's a good idea. r1362480.

Ivan Zhakov
Received on 2012-07-17 15:39:22 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.