{"id":19295,"date":"2022-12-09T09:43:04","date_gmt":"2022-12-09T08:43:04","guid":{"rendered":"https:\/\/herolab.usd.de\/?page_id=19295"},"modified":"2022-12-16T12:13:14","modified_gmt":"2022-12-16T11:13:14","slug":"usd-2022-0042","status":"publish","type":"page","link":"https:\/\/herolab.usd.de\/en\/security-advisories\/usd-2022-0042\/","title":{"rendered":"usd-2022-0042"},"content":{"rendered":"

[et_pb_section fb_built=\"1\" _builder_version=\"4.16\" _module_preset=\"default\" background_color=\"#2E353D\" custom_padding=\"||0px|||\" global_colors_info=\"{}\"][et_pb_row _builder_version=\"4.16\" _module_preset=\"default\" custom_padding=\"|0px||||\" hover_enabled=\"0\" global_colors_info=\"{}\" sticky_enabled=\"0\"][et_pb_column type=\"4_4\" _builder_version=\"4.16\" _module_preset=\"default\" global_colors_info=\"{}\"][et_pb_text _builder_version=\"4.19.2\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\" width=\"100%\" custom_margin=\"|2px|20px||false|false\" custom_padding=\"|8px||||\" hover_enabled=\"0\" global_colors_info=\"{}\" sticky_enabled=\"0\"]<\/p>\n

<\/h1>\n

usd-2022-0042 | Dependecy Confusion in GitLab<\/h1>\n

<\/h1>\n

Advisory ID<\/strong>: usd-2022-0042
Product<\/strong>: GitLab
Affected Version<\/strong>: GitLab Community Edition 15.2.2, probably others...
Vulnerability Type<\/strong>: Uncontrolled Search Path Element (CWE-427)
Security Risk<\/strong>: High
Vendor URL<\/strong>: https:\/\/gitlab.com<\/a>
Vendor acknowledged vulnerability<\/strong>: No
Vendor Status<\/strong>: Not fixed<\/p>\n

Affected Component(s)<\/h3>\n

The vulnerability affects the Python Package Registry<\/em> that can be configured for distributing internal packages.<\/p>\n

Description<\/h3>\n

pip<\/em> is probably the most popular Python<\/em> package manager and can be used to install packages from the publicly
available Python Package Index<\/em> (PyPi<\/em>) at pypi.org<\/a> or form internal package repositories. In the beginning of 2021,
a vulnerability type called Dependency Confusion<\/em> attracted some attention in the information security scene. Several
high profiled companies were identified to accidentally load internal dependencies from the public available index
at PyPi<\/em>. This could have allowed any PyPi<\/em> user to register packages with the accidentally requested names
and to achieve remote code execution on the affected systems.<\/p>\n

The underlying reason for the vulnerability was the usage of the --extra-index-url<\/strong> parameter when installing packages
via pip<\/em>. This parameter adds additional packages sources where pip<\/em> checks for the desired installation candidate. That
being said, the publicly available index at PyPi<\/em> remains within the sources and will be used if the requested version
of the desired package can be found. In case of no version was specified, pip<\/em> installs the most recent version it finds
among all configured repositories.<\/p>\n

After the Dependency Confusion<\/em> got publicly known, the general recommendation was to use --index-url<\/strong> instead of
--extra-index-url<\/strong>, which replaces pypi.org<\/a> as the default package registry. GitLab<\/em>, however, still advises it's
users to use --extra-index-url<\/strong> within the web overview of a projects package registry. Therefore, users that are not
aware of Dependency Confusion<\/em>, might accidentally install internal GitLab<\/em> packages from the publicly available index
at PyPi<\/em>.<\/p>\n

Moreover, with version 14.2<\/strong>, GitLab<\/em> made even usage of --index-url<\/strong> not fail save. According to the
documentation<\/a>:<\/p>\n

\n

In GitLab 14.2 and later, when a PyPI package is not found in the Package Registry, the request is forwarded to pypi.org.<\/p>\n<\/blockquote>\n

This configuration can lead to dangerous side effects when installing internal packages with other internal dependencies
or when using --index-url<\/strong> with another internal URL in the --extra-index-url<\/strong> parameter. GitLab<\/em> defines package registries on the project and group level. If package dependecies cross these project or group boundaries, dependecy confusion is possible.<\/p>\n

Proof of Concept<\/h3>\n

First, we create a simple python project usd-example-package<\/strong> and make it available over the projects package
registry within GitLab<\/em>. Viewing the webpage of the newly created package, it shows the following installation command:<\/p>\n

\"\"<\/p>\n

As one can see, the suggested install command uses the --extra-index-url<\/strong> by default, which makes it vulnerable to
dependency confusion.<\/p>\n

Now lets go one step further. Within our example package, we add an internal dependency usd-example-dependecy<\/strong>. This dependency is contained within another project and we add --extra-index-url<\/strong> to include this within the repository sources.
The installation command now looks like this:<\/p>\n

\n
<\/span>$ <\/span>pip install usd-example-project --index-url [<\/span>https:\/\/gitlab.example.com\/api\/v4\/projects\/10\/packages\/pypi\/simple]()<\/span> --extra-index-url [<\/span>https:\/\/gitlab.example.com\/api\/v4\/projects\/11\/packages\/pypi\/simple]()<\/span><\/pre>\n<\/div>\n
Since --index-url<\/strong> was used, pypi.org<\/a> should not be considered when searching for packages and the installation command should be safe, right? Well, after launching the command, pip<\/em> first loads usd-example-project<\/strong> from the URL specified as --index-url<\/strong>:<\/p>\n
\n
<\/span>GET<\/span> \/api\/v4\/projects\/10\/packages\/pypi\/simple\/usd-example-dependecy\/<\/span> HTTP<\/span>\/<\/span>1.1<\/span>\nHost<\/span>:<\/span> gitlab.example.com<\/span><\/pre>\n<\/div>\n
Afterwards, the --extra-index-url<\/strong> is checked as described above, but since it belongs to our internal trusted GitLab<\/em> instance, this should be fine:<\/p>\n
\n
<\/span>GET<\/span> \/api\/v4\/projects\/11\/packages\/pypi\/simple\/usd-example-project\/<\/span> HTTP<\/span>\/<\/span>1.1<\/span>\nHost<\/span>:<\/span> gitlab.example.com<\/span><\/pre>\n<\/div>\n
However, since usd-example-package<\/strong> is only distributed within the project with ID 10, the registry for project ID 11 will not find the requested package and forward the request to PyPi<\/em>:<\/p>\n
\n
<\/span>HTTP<\/span>\/<\/span>1.1<\/span> 302<\/span> Found<\/span>\nLocation<\/span>:<\/span> [https:\/\/pypi.org\/simple\/usd-example-project\/]()<\/span><\/pre>\n<\/div>\n
Now, although we used --index-url<\/strong>, we are again vulnerable to dependency confusion.<\/p>\n
Fix<\/h3>\n
The reported issue should be fixed by making the following adjustments:<\/p>\n
    \n
  1. The insecure installation command suggested by the repository webpages should be replaced. Instead of --extra-index-url<\/strong>, the --index-url<\/strong> command line option should be chosen.<\/li>\n
  2. Forwarding of requests for unknown packages to pypi.org<\/a> should be disabled by default. This setting can have dangerous side effects and should not be enabled by default. Administrators that understand the consequences could still enable the feature for their instance.<\/li>\n<\/ol>\n
    We are aware that automatic forwarding of unknown packages to PyPi<\/em> increases the usability of internal package registries quite a lot. Installation of internal tools and dependencies usually also requires installation of packages that are available on PyPi<\/em>. Restricting the index to an internal repository makes automatic installation of these external dependencies fail, which creates some additional installation effort.
    That being said, the accidental installation of potentially malicious software from a public package registry represents a high security risk for organisations and should be classified as more important as usability.<\/p>\n
    Another possible solution would be to only allow forwarding requests to PyPi<\/em> for packages that are not available within the whole internal GitLab<\/em> instance.<\/p>\n
    References<\/h3>\n