Admin access vulnerability in user repository creation (non-deterministic)

Issue #331 resolved
Mika Myllynen
created an issue

In our organisation's internal security audit another vulnerability which enables logged in user to gain admin permissions was found. This vulnerability is non-deterministic in nature (ie. there are no exact steps to reproduce it 100% of the time) so it is a bit hard to describe but I will do my best with the information I got:

The userrepo plugin creates the repository with (temporarily) elevated permissions. In some rare conditions it is possible that the permissions are not restored to the original level and as a result, the user session continues with administrator privileges.

The SCM Manager application logs show a lot of repository creation activities and Java errors during the issue:

10:58:26.926 [TP-Processor28] INFO - user testuser executes sonia.scm.userrepo.CreateUserRepositoryAction as admin
10:58:26.926 [TP-Processor28] INFO  sonia.scm.repository.DefaultRepositoryManager - create repository Testing2 of type git
10:58:26.946 [TP-Processor28] ERROR sonia.scm.userrepo.UserRepositoryResource - could not create new repository
java.lang.RuntimeException: sonia.scm.repository.RepositoryAllreadyExistExeption

We think this may be a some kind of threading issue and that's why it is not always reproducible. It may require that several threads try to create the same repository at the same time. In the normal user flow of things, this would never happen, but using a vulnerability scanner with multiple concurrent scanning threads does just that.

Additionally, it may require that the creation thread crashes. The SCM Java code in uses a try-finally block to handle the privileged run and the finally block downgrades the privileges. However, if the thread created in the try block dies, the finally block is never executed.

Steps you could try to reproduce this:

  • Obtain, install and execute OWASP ZAP 2.0
  • Start browser and configure it to route all traffic via the ZAP local proxy.
  • Log in to SCM Manager as non-privileged user (we have LDAP users, YMMV).
  • Create a repository so that the creation plugin URL is caught by ZAP.
  • Configure ZAP Analyse -> Scan policy to scan only
    • LDAP injection
    • all SQL injections Disable the rest.
  • Ensure you have at least 3 concurrent threads (5 is the best bet) per host in Tools->Options->Active Scan.

Right click on the SCM site host name on the ZAP Sites tab. Select Attack -> Active scan site in the context menu.

When the active scan has finished, refresh your SCM front page and you will hopefully find yourself logged in as scmadmin. Since the creation tests are run somewhere in the middle of the test run, you can test your userid status by refreshing the SCM front page even in the middle of the scans.

This works about 50% of the time. If it does not work the first time, log out and log in again. Ensure that your new session id is selected active in the Http Sessions -tab. Rerun the Active scan and it hopefully works.

Comments (6)

  1. Sebastian Sdorra repo owner
    • changed status to open

    After a lot of test, i could reproduce this issue. It looks like we hit SHIRO-380. The issue does not occur with the latest snapshot of Shiro 1.2.2/1.3.0. As soon as the scm-manager repositories are back online, i will create a test version with the latest shiro snapshot.

  2. Mika Myllynen reporter

    Unfortunately I was unable to test it, I could not reproduce the problem myself. The person who did the security audit is not available for some time but I will try to look into this more with another colleague or two tomorrow. Sorry for the delay, will try to get back into this asap.

  3. Log in to comment