Project Repository Settings page shows 500 error when stored mirror URL is invalid
HackerOne report #559229 by apogiatzis
on 2019-05-01, assigned to estrike
:
Summary
Project Repository settings become unavailable and always return an internal server error when a URL that can't be parsed by ruby URL parser is given. As a result, a denial of service attack is possible that prevents users from altering any project settings from the "Repository Tab"
Steps to reproduce
Please follow the steps below to reproduce the
- Create a new GitLab Project
- From the sidebar click Settings->Repository
- Click "Expand" on the "Mirroring repositories" section
- Enter the URL below in the Git Repository URL field and click "Mirror Repository"
http://[0:0:0:0:ffff:123.123.123.123]/foo.git
- A 500 Internal server error should be displayed
- Now every time that you attempt to access Settings->Repository a 500 Internal Server error will be returned thus preventing users from accessing Repository settings
Impact
As this is only a Denial of Service attack, nothing sensitive is leaked or exposed. However, from my experiments, I realised that I couldn't revert the 500 error unless I had access to the server hosting the GitLab app. Although this requires significant effort, for users that host a local GitLab version, they should be able to revert the error if the tweak the project settings manually from the server terminal. However, for users using the global online GitLab version, this can be a serious Denial of Service attack as they won't be able to alter any repository settings.
What is the current bug behavior?
Project Repository Settings return a 500 internal server error when the bug is triggered
What is the expected correct behavior?
Project Repository Settings should be accessed normally even when the URL could not be parsed
Results of GitLab environment info
By inspecting the issue on a hosted gitlab server it seems that the following error occurs:
bad URI(is not URI?): http://[0:0:0:0:ffff:123.123.123.123]/foo.git
at
app/models/remote_mirror.rb:171
This can be verified from the logs in:
/var/log/gitlab/gitlab-rails/production.log
Impact
As this is only a Denial of Service attack, nothing sensitive is leaked or exposed. However, from my experiments, I realised that I couldn't revert the 500 error unless I had access to the server hosting the GitLab app. Although this requires significant effort, for users that host a local GitLab version, they should be able to revert the error if the tweak the project settings manually from the server terminal. However, for users using the global online GitLab version, this can be a serious Denial of Service attack as they won't be able to alter any repository settings.
Attachments
Warning: Attachments received through HackerOne, please exercise caution!