You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bert Huijben <rh...@sharpsvn.net> on 2009/02/05 15:04:08 UTC

Transaction names in post Uris webdav

[I sent this mail to the dev list; not the security list... as this part
of the HTTPv2 protocol is not even implemented right now!]

	Hi,

Our webdav implementation creates a public Uri to communicate over when
a transaction is started and closes it when the transaction is
committed. (Or aborted?).

Anyway, in HTTPv1 we generated a UUID and used that as the public
transaction ID. This made it impossible to guess the transaction ID for
outstanders that didn't start the transaction.
(As far as I know everyone can write to this public Uri when they get
through the initial security check).

For HTTPv2 the decision was made to no longer create a generated UUID ->
Filesystem transaction mapping, but to use the real transaction ID used
by the filesystem in the Uri.

This might introduce a security problem, as it is certainly possible to
guess a filesystem transaction id. (I think FSFS uses two integers as
the transaction id.. the first of which specifies at which revision the
transaction started).


I don't know our webdav protocol and its emplementation well enough to
be sure that this is actually a security problem. (Or that we just store
the author in the transaction and verify that on every transaction
update). But I want to make sure we don't introduce a backdoor where..

The attack vector I'm afraid of is:

Lets assume I know UserX is working on the WC library ... 
* That would make trunk/subversion/libsvn_wc a likely transaction root.
* I continuously try to write a new deprecated.c to this transaction
root based on the guessed transaction numbers.. and voila in one of the
thousands of requests I guess the transaction correctly, so it actually
succeeds.

Eventually UserX commits his transaction, but he commits deprecated.c
with it.

So in this case I can changed his transaction, without any trace in the
history. (And probably break his working copy too)..


Is this a realistic attack?

I surely hope it isn't... 
But I want to be sure... So please shoot on this guessing..

Thanks,

	Bert

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1107805


RE: Transaction names in post Uris webdav

Posted by Bert Huijben <rh...@sharpsvn.net>.
> -----Original Message-----
> From: sussman@gmail.com [mailto:sussman@gmail.com] On Behalf Of Ben
> Collins-Sussman
> Sent: donderdag 5 februari 2009 17:03
> To: Bert Huijben
> Cc: dev@subversion.tigris.org
> Subject: Re: Transaction names in post Uris webdav
> 
> I don't think there's a realistic attack vector here, for two reasons:
> 
> 1. Most (sane) apache configurations only allow authenticated commits.
>  So even if an attacker could guess the name of a
> transaction-in-progress, they would still have to be an authenticated
> commiter to do a PUT at all.   Teams which allow anonymous commits...
> well, they deserve what they get.  :-)
> 
> 2. mod_dav_svn already prevents 'multi-author' commits.  Whenever a
> PUT comes in on a transaction, it checks that the authenticated
> username on the PUT matches the transaction's existing svn:author
> property.  (If there's no svn:author property yet, it creates it.)
> For details, see mod_dav_svn/repos.c:prep_working().

	Hi,

The attack vector I was thinking of was closed by point 2. And thanks for
the source reference :)

Thanks for confirming we didn't forget something here!

	Bert

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1108126

Re: Transaction names in post Uris webdav

Posted by Ben Collins-Sussman <su...@red-bean.com>.
I don't think there's a realistic attack vector here, for two reasons:

1. Most (sane) apache configurations only allow authenticated commits.
 So even if an attacker could guess the name of a
transaction-in-progress, they would still have to be an authenticated
commiter to do a PUT at all.   Teams which allow anonymous commits...
well, they deserve what they get.  :-)

2. mod_dav_svn already prevents 'multi-author' commits.  Whenever a
PUT comes in on a transaction, it checks that the authenticated
username on the PUT matches the transaction's existing svn:author
property.  (If there's no svn:author property yet, it creates it.)
For details, see mod_dav_svn/repos.c:prep_working().

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1108001