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.