Namespace path cleaning vulnerable to regular expression denial of service

Summary

The regular expression used to remove trailing ., .git or .atom from namespace paths is vulnerable to regular expression denial of service due to backtracking issues when provided with a long malicious string.

Steps to reproduce

Demonstration on the command line

ruby -e '("."*50000+"!").gsub!(/(\.atom|\.git|\.)*\z/, "")'

This line will max out the CPU at 100% until killed.

This regex runs on input from external systems when provisioning accounts as seen by this search but I don't want to test this on gitlab.com.

I might setup something locally for a better PoC, but I think I can come up with a fix instead of doing that and save the same. :)

Example Project

What is the current bug behavior?

A malicious string can cause a maxed out CPU on the server. Repeating the attack could tie up a lot of resources on the machine running GitLab.

What is the expected correct behavior?

Path should be cleaned in constant time.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)
(we will only investigate if the tests are passing)

Proposal

In Namespace, replace gsub with loop as proposed below.

Other proposals considered

• Introduce a sensible max length limit for the path.