Currently it's possible to hijack pages with unique domain URLs. This is permitted because the current format of pages unique domains is namespace-subgroup-...-project-<RANDOM STRING>. Once this value is known, one can create a namespace (User or Group) with that random string and then a Gitlab Pages for that namespace (https://docs.gitlab.com/ee/user/project/pages/getting_started_part_one.html#gitlab-pages-default-domain-names), which will have priority on the URL lookup, hijacking the traffic. Example:
Instead of using - as the separator on the unique URL, use *.
* are valid URL chars, but are not valid as project/group name/path, preventing malicious users to create projects that could end-up with the same URL as a Pages Unique Domain URL.
IMO it's too late to treat the feature as beta when it has been adopted by a few hundred projects. We should patch it and I don't see a way to do this in a non-disruptive way (i.e. by changing already created URLs) but should inform inform customers their the URLs they've been using will break. @mmacfarlane Do you know the best way we could do this?
IMO it's too late to treat the feature as beta when it has been adopted by a few hundred projects. We should patch it and I don't see a way to do this in a non-disruptive way (i.e. by changing already created URLs) but should inform inform customers their the URLs they've been using will break.
@mmacfarlane Do you know the best way we could do this?
@johnhope This is a challenging situation. We could wait for 17.0 and technically categorize this as a "breaking change" but then we risk continued exposure which just exacerbates the Issue.
Mitigation now is better but I'm uncertain of the best path.
@kassio@johnhope Do we have FF opt in data granular enough to see all customers opted in?
@amandarueda@gweaver Can I get your advice here? TLDR we need to implement a security fix but it will impact a small subset of users as it will break URLs they've been leveraging. What action(s) can we take, other than waiting until 17.0, to inform these specific subset of users their URLs will be impacted?
IMO it's too late to treat the feature as beta when it has been adopted by a few hundred projects.
It seems that we may know who will be affected. If that is the case, I'd propose an email campaign to those users giving them 90 days notice of the change, along with self-remediation steps if that is possible (can they change the name to avoid the issue)?
We could wait for 17.0 and technically categorize this as a "breaking change" but then we risk continued exposure which just exacerbates the Issue.
@mmacfarlane Unfortunately we can't do that as we can't leave an open vulnerability for that long. The SLA on a severity3 is 90 Days.
We would also have to announce the breaking change at the same time as releasing the fix, which would force customers to rush a major version upgrade, or leave their instance vulnerable to a publicly disclosed vulnerability.
Communicating to customers directly sounds like a good idea. We will only know who that is on GitLab.com, however. We'll also need to communicate to self-hosting customers but that should be easier as we can include it in patch notes for the security patch?
You could broadcast a message in 16.3, then make the breaking change in 16.4.
If that doesn't work, the best thing to do is figure out how to communicate via as many channels as possible what is happening when the breaking change takes place.
This vulnerability was rated severity3 on 2023-06-27,
and must be fixed within 90 days.
To meet the remediation SLA, the change must make it into the security release
before 2023-09-22 (the monthly release date before the remediation SLA).
After some thought, given that I couldn't identify any exploited projects yet, instead of changing the unique domain (for now), I propose to add a validation on project creation/update to not permit new project with existing pages unique domain.
In other words, when creating or updating a project path, check if that path already exist as a pages unique domain, if so, do not permit the create/update.
Thanks a lot @kassio. One small concern, do you see any way an attacker could leverage this to 'squat' on common/popular project paths? They would need access to the group hierarchy in the path name, right?
BTW if you've started work on this should it be in workflowin dev ?
do you see any way an attacker could leverage this to 'squat' on common/popular project paths?
Can you clarify what a squat would be in this context, please? I don't see any other possible exploitation paths beyond the one described in the issue, but just to be sure, let's clarify you scenario.
BTW if you've started work on this should it be in workflowin dev
I meant to ask that if we would validate unique pages domains before allowing to change a group/project path, would it be possible for a malicious user to 'block' a target path in advance.
For example, say GitLab had a new project called Trio, would an attacker be able to block us from placing the project at the path gitlab-org/trio by configuring a unique pages domain like gitlab-org-trio that blocked this path?
I don't think it is possible though, as they'd need to have access to the gitlab-org hierarchy in the first place and a random string is appended anyway?
For example, say GitLab had a new project called Trio, would an attacker be able to block us from placing the project at the path gitlab-org/trio by configuring a unique pages domain like gitlab-org-trio that blocked this path?
This wouldn't be possible because the users don't choose the unique domain path, it's generated based on the project full path. For instance if a project user/project starts using unique domain, we'd generate a domain like project-user-9a32916a4408a13c37423243b990959a6cfdc808ebf8343c7b.