Update attack complexity metric for CVE-2023-5009

What does this change do?

Updates Attack Complexity CVSS metric from AC:L to AC:H for CVE-2023-5009.

Why?

A successful attack on self-managed GitLab:

• depends on conditions beyond the attackers control
• requires the self-managed GitLab instance to be using an "_un_reasonable configuration" (one that "conflicts with official documented configuration guidance") in production

A successful attack depends on conditions beyond the attacker's control because the "Direct transfer" feature must be enabled to exploit this vulnerability, and this feature is disabled-by-default. This feature must be explicitly enabled by a Gitlab administrator for a successful attack to occur. Because attackers don't have control over admin-level settings, a successful attack on self-managed "depends on conditions beyond the attackers control".

Additionally, successful attack on self-managed GitLab depends on the GitLab instance having an Ultimate license applied. Only GitLab administrators can apply Ultimate licenses. As this can't be exploited on any instance without an Ultimate license applied, and the attacker does not have the ability to apply or change an instance's license, this is another example of how exploitation of this vulnerability "depends on conditions beyond the attackers control".

GitLab also explicitly warns throughout our official "documented configuration guidance" that the direct import feature is "in beta" and "not ready for production use"

• https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/user/group/import/index.md?plain=1#L52-54
• https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/user/group/import/index.md?plain=1#L43
• https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/user/project/import/index.md?plain=1#L20-21
• https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/user/project/import/index.md?plain=1#L28-29

Because this configuration conflicts with our official documentted configuration guidance, it is an example of an "_un_reasonable configuration":

Unreasonable configurations are those that deliberately place the target in a vulnerable state, e.g., by disabling security features, or that conflict with documented configuration guidance, e.g., by using a non-default configuration that a product vendor explicitly states should never be used.

Because a successful attack on self-managed GitLab a) depends on conditions outside the attackers control and b) requires access to a GitLab instance using an "_un_reasonable configuration" (one that goes against the software vendor's documented configuration guidance), AC:H is more appropriate than AC:L for attack complexity.

/label ~"devops::secure" ~"group::vulnerability research" ~"vulnerability research::advisory"