CVE-2018-16976 (Other, published 2018-09-12T22:29Z)
Description: value: Gitolite before 3.6.9 does not (in certain configurations involving @all or a regex) properly restrict access to a Git repository that is in the process of being migrated until the full set of migration steps has been completed. This can allow valid users to obtain unintended access.
Severity: MEDIUM (CVSS v3 base score: 8.1)
Weakness: CWE-362 \u2014 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.
Repository: https://github.com/sitaramc/gitolite
Files changed:
src/gitolite-shell
src/lib/Gitolite/Common.pm
Commit message: prevent access to repos which are in the process of bring migrated

Björn Kautler pointed out that, when a repo is being migrated into
gitolite as per the documentation [1], there is a gap between the actual
move of the repo and the rest of the process where a user can gain read
or write access to the repo, which he would *not* have had after the
completion of the process.

My first thought was to document this, and advise people to use the
'writable' command to disable writes, but there is nothing as simple and
painless to prevent reads.  (On the plus side, this kind of racy read
access can only happen if the conf is using the "deny-rules" option to
restrict reads; without that, it makes no difference -- i.e., he gets no
access that he would not have got later anyway).

But eventually I realised that documentation was frustrating, for
various reasons, and that at least in this case there is a way to fix it
in the code -- just block all access to a repo that is in
~/repositories, but which does not yet have the update hook setup
correctly.  Plus, the code does not impact anything else, and is
basically just an extra check.

[1]: http://gitolite.com/gitolite/basic-admin/index.html#appendix-1-bringing-existing-repos-into-gitolite


Vulnerable code:
            push @phy_repos, $repo unless $repo =~ m(/$);
                # tolerate bare repos within ~/repositories but silently ignore them

Fixed code:
    # catch rare race when moving repos into gitolite control
    _die "$aa any $repo $user DENIED by fallthru" .
            "\n(or you mis-spelled the reponame)"
        unless update_hook_present($repo);
    # this error message is exactly the same as that from elsewhere in the
    # code, for the usual reasons (avoid leaking information)


          update_hook_present
            next if $repo =~ m(/$);
                # tolerate non-bare repos within ~/repositories but silently ignore them
            next unless update_hook_present($repo);
                # ignore repos that don't yet have the update hook
            push @phy_repos, $repo;
sub update_hook_present {
    my $repo = shift;

    return 1 unless -d "$ENV{GL_REPO_BASE}/$repo.git";  # non-existent repo is fine

    my $x = readlink("$ENV{GL_REPO_BASE}/$repo.git/hooks/update");
    return 1 if $x and $x eq "$ENV{GL_ADMIN_BASE}/hooks/common/update";

    return 0;
}