Security compromise - Restricted svn areas accessible through changeset browsing

[dan@…]

Here is my auth file:

[groups]
dev = a, b

[repos:/]
@dev = rw

[repos:/project]
@dev = rw

[repos:/secretproject]
* =
a = rw

The repository looks like this:

 /
 +- project
 |
 +- secretproject
   |
   +- src
     |
     +- secretfile.cpp

I checked in secretproject in changeset 10

User a has full access to everything as expected. User b when clicking on the Browse Source button does not see secretproject. This is also expected.

In the Timeline, user b can see that changeset 10 happened. When viewing changeset 10, user b sees the following:

Files: src/secretfile.cpp

I would expect user b to not see any of the files under the secretproject directory.

If user b clicks on this file, the change set IS displayed, and the following URL is what gets this user to the file:

https://server.mycompany.com/trac/tracproject/browser/src/secretfile.cpp?rev=10

Once I have clicked on this link and viewed the file at changeset 10, an unexpected thing happens when I click back to Browse Source. At this point, the compromised directory shows up and I can browse down the src tree:

 /
 +- project
 |
 +- src
   |
   +- secretfile.cpp

[Noah Kantrowitz]

Please try using 0.10.4, many issues with this feature have been resolved since then.

[anonymous]

Replying to nkantrowitz:

Please try using 0.10.4, many issues with this feature have been resolved since then.

I finally had the time to upgrade. I'm working on 0.10.4, and the behavior as described above looks identical.

I'm changing the properties of this ticket to version 0.10.4

[ThurnerRupert]

we are using 0.10.3 and do not see change sets of view restricted things nor the files itself via browse source. you are sure you entered the correct parameters, see e.g. ​http://lists.edgewall.com/archive/trac/2006-August/009131.html?

pls reopen if i am wrong.

what i did not check if subdirectories are restricted and a change set includes partially view restricted and not view restricted files.

[Noah Kantrowitz]

Nothing personal, but a core dev (preferably cboos since he knows this system the best probably) should really sign off on this first. Security issues need to be verified carefully.

[anonymous]

Replying to ThurnerRupert:

we are using 0.10.3 and do not see change sets of view restricted things nor the files itself via browse source. you are sure you entered the correct parameters, see e.g. ​http://lists.edgewall.com/archive/trac/2006-August/009131.html?

pls reopen if i am wrong.

what i did not check if subdirectories are restricted and a change set includes partially view restricted and not view restricted files.

It looks as though I may have left out a critical details of this bug:

Change sets under the restricted areas are protected except for the initial checkin.

I'm did quite a bit more work with this yesterday and ran into this issue consistently when I checked the permissions. Is it possible that as I move things from a non-protected area into a protected area that the permissions might get strange? As a note: svn permissions are checked and guarded correctly.

If one of you would like to see actual screen shots of this behavior or a one-on-one demo of this, please feel free to contact me.

[anonymous]

Replying to anonymous:

Replying to ThurnerRupert:

we are using 0.10.3 and do not see change sets of view restricted things nor the files itself via browse source. you are sure you entered the correct parameters, see e.g. ​http://lists.edgewall.com/archive/trac/2006-August/009131.html?

pls reopen if i am wrong.

what i did not check if subdirectories are restricted and a change set includes partially view restricted and not view restricted files.

It looks as though I may have left out a critical details of this bug:

Change sets under the restricted areas are protected except for the initial checkin.

I'm did quite a bit more work with this yesterday and ran into this issue consistently when I checked the permissions. Is it possible that as I move things from a non-protected area into a protected area that the permissions might get strange? As a note: svn permissions are checked and guarded correctly.

If one of you would like to see actual screen shots of this behavior or a one-on-one demo of this, please feel free to contact me.

OK… On further investigation, new areas that are added that have security enabled seem to be protected just fine with 10.4. It looks like areas that were moved out from public areas and into private areas are not protected correctly.

i.e.: SecretProject/src/secretfile.cpp (moved from Project/secretfile.cpp) is granting access to see SecretProject/src/secretfile.cpp in the changeset where the file was moved. Although I don't like the way this behaves, the file was in the non-restricted area at some point in the past. Is this truly a bug? Is it a behavior that can be changed?

[Christian Boos]

Replying to anonymous:

i.e.: SecretProject/src/secretfile.cpp (moved from Project/secretfile.cpp) is granting access to see SecretProject/src/secretfile.cpp in the changeset where the file was moved. Although I don't like the way this behaves, the file was in the non-restricted area at some point in the past. Is this truly a bug? Is it a behavior that can be changed?

I think converting the svn_authz.py to a real permission policy should fix that issue.

[Christian Boos]

Tentatively put back to 0.12.

[Remy Blank]

Isn't this fixed now with the AuthzSourcePolicy?

[Remy Blank]

Closing as fixed (by the new AuthzSourcePolicy).