Credentials configured on self-hosted Shields instances may be sent to arbitrary URLs #4730
Labels
security
Refer to our SECURITY.md policy before opening pull requests that address a security vulnerability
self-hosting
Discussion, problems, features, and documentation related to self-hosting Shields
Discussion thread for GHSA-6qx4-g993-2225
Who is affected?
Who is unaffected?
Users of the centralized service, https://shields.io/
Users of the gh-badges npm package.
Self-hosting users who have not set credentials for any of the eight services listed below.
Impact
Users who host their own copy of Shields have the ability to configure credentials for several of the external services. Several of the badges provided by Shields allow users to specify the target URL/server of the upstream instance to use via a query parameter in the badge URL. This supports scenarios where your users may need badges from multiple upstream targets, for example if you have more than one Nexus server. When credentials are configured for one of these services, a request could trivially be crafted to exploit this feature, sending the credentials to any URL (and in most cases over either HTTP or HTTPS).
Credentials for the following services are affected:
Patches
The problem was fixed in PR #4729. Self-hosting users are recommended to upgrade immediately. We recommend revoking and regenerating any configured credentials for the affected services.
If you need time to do this, please remove the credentials from the configuration until then.
If you install from dockerhub,
docker pull shieldsio/shields:next
to update to the latest version.When using credentials with services that accept arbitrary URLs, the authorized URLs must now be configured too, or else the credentials will not be set. See the documentation on configuring server secrets for more info. It is highly recommended to use
https
origins with valid SSL, to avoid the possibility of exposing your credentials, for example through DNS-based attacks.One service, Jenkins, allows strict SSL checking to be disabled using a query parameter in the badge URL. This is supported for interoperability reasons (#1956). (Since the Jenkins service also supports HTTP to arbitrary hosts, credentials being sent over non-strict SSL may not represent a further vulnerability.) When using Jenkins, the
disableStrictSsl
option must now be enabled in configuration (otherwise those requests won't fire). When using Jenkins with credentials, the credentials will not be sent todisableStrictSsl
requests, unless this is specifically enabled in configuration.Workarounds
To remediate the vulnerability without upgrading, remove the configured secrets from the configuration. This will prevent them from being sent with any request.
We also recommend revoking and regenerating any configured credentials for the affected services.
If you have any questions or comments about this, ask below or contact us on Discord.
The text was updated successfully, but these errors were encountered: