transport: block redirects from token server to private/link-local addresses (SSRF fix) by evilgensec · Pull Request #2292 · google/go-containerregistry (original) (raw)
refreshOauth and refreshBasic constructed http.Client without a CheckRedirect handler, allowing a malicious token server to issue an HTTP redirect to an internal address (e.g. 169.254.169.254) that would pass the initial validateRealmURL check but still reach private services.
Add realmRedirectCheck, which applies the same scheme and private-IP restrictions as validateRealmURL to every redirect hop during a token-fetch request. Wire it as CheckRedirect on both clients.
Add TestTokenServerRedirectSSRF to confirm the redirect is rejected.
4 tasks
- Shorten realmRedirectCheck doc comment.
- Extract allowInsecure local in refreshOauth and refreshBasic.
- Drop redundant inline comment in TestTokenServerRedirectSSRF.
Subserial pushed a commit to Subserial/go-containerregistry that referenced this pull request
…dresses (SSRF fix) (google#2292)
- transport: block redirects from token server to private addresses
refreshOauth and refreshBasic constructed http.Client without a CheckRedirect handler, allowing a malicious token server to issue an HTTP redirect to an internal address (e.g. 169.254.169.254) that would pass the initial validateRealmURL check but still reach private services.
Add realmRedirectCheck, which applies the same scheme and private-IP restrictions as validateRealmURL to every redirect hop during a token-fetch request. Wire it as CheckRedirect on both clients.
Add TestTokenServerRedirectSSRF to confirm the redirect is rejected.
- transport: address review feedback
- Shorten realmRedirectCheck doc comment.
- Extract allowInsecure local in refreshOauth and refreshBasic.
- Drop redundant inline comment in TestTokenServerRedirectSSRF.
- transport: rename unused handler param to satisfy revive linter
Subserial pushed a commit that referenced this pull request
- fix: prevent SSRF in google.List() pagination
Add URL validation to getNextPageURL() to ensure pagination Link headers point to the same registry host. This prevents SSRF attacks where a malicious registry could include a Link header pointing to internal services like cloud metadata endpoints (169.254.169.254).
The fix validates that:
- The pagination URL scheme matches the registry scheme
- The pagination URL host matches the registry host
This is consistent with SSRF protections added in PRs #2292, #2293, #2295 for other code paths.
- fix: also prevent SSRF in remote.List() and remote.Catalog() pagination
The same SSRF vulnerability that affected google.List() also exists in remote.List() and remote.Catalog(). A malicious registry can return a Link header pointing to internal services.
This commit adds SSRF protection to the remote package's pagination handling, using the same validation approach.
- fix: update remote list_test.go for getNextPageURL signature change
Update test calls to getNextPageURL in pkg/v1/remote/list_test.go to pass the required name.Repository argument, matching the new function signature that includes SSRF validation.
Also update makeResp helper to include a Request with URL for proper ResolveReference behavior, and adjust test assertions accordingly.
fix: treat empty Link header URL as no next page
fix: restore missing <> test case and add SSRF test to remote package
Co-authored-by: tufstraka tufstraka@users.noreply.github.com
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})