Advisoriesby Ibis`RegistryClient` follows the `WWW-Authenticate` realm without validating its host or scheme
Impact
A remote attacker who controls a container registry may be able to direct a client's token request to a host of the attacker's choice, and disclose the victim's registry credentials to that host.
The client issues that request from the victim's host, which gives the attacker reach into networks that only the victim can address. Where the attacker names an internal service that answers an unauthenticated request with a JSON token or access_token field, the client returns that value to the attacker's registry. The attack needs only an operation that contacts the attacker's registry with credentials, including a login attempt that fails, because the client sends the credentials before it stores them.
Details
A registry that answers 401 or 403 may supply a WWW-Authenticate: Bearer challenge, whose realm parameter names the authorization server. The client used the realm value as the token endpoint without any check on its host or scheme, and attached the configured credentials to that request. The client also attached the configured credentials to the registry request itself, and presented any token from the realm host to the registry on the retry.
Three problems follow from the missing check:
1. SSRF — the attacker chooses which host the client contacts, including link-local and private addresses.
2. Conditional token exfiltration — the...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| apple/containerization Product | < 0.41.0 | 0.41.0 |
Details and references
## Impact A remote attacker who controls a container registry may be able to direct a client's token request to a host of the attacker's choice, and disclose the victim's registry credentials to that host. The client issues that request from the victim's host, which gives the attacker reach into networks that only the victim can address. Where the attacker names an internal service that answers an unauthenticated request with a JSON `token` or `access_token` field, the client returns that value to the attacker's registry. The attack needs only an operation that contacts the attacker's registry with credentials, including a login attempt that fails, because the client sends the credentials before it stores them. ## Details A registry that answers `401` or `403` may supply a `WWW-Authenticate: Bearer` challenge, whose `realm` parameter names the authorization server. The client used the `realm` value as the token endpoint without any check on its host or scheme, and attached the configured credentials to that request. The client also attached the configured credentials to the registry request itself, and presented any token from the realm host to the registry on the retry. Three problems follow from the missing check: 1. **SSRF** — the attacker chooses which host the client contacts, including link-local and private addresses. 2. **Conditional token exfiltration** — the attacker receives a token that belongs to an internal service. 3. **Cleartext credential exposure** — the realm scheme is unchecked, so the credentials travel over plain HTTP when the challenge asks for it. For a registry configured as insecure, an attacker in a privileged network position injects the challenge and harvests the credentials directly. Credential disclosure to the registry host is largely redundant, because the client already sent the same credentials to that registry on the first request. The problems that are not redundant are the SSRF, the conditional token exfiltration, and the credential disclosure to a realm host other than the registry. ## Affected code `fetchToken` and `createTokenRequest` in `Sources/ContainerizationOCI/Client/RegistryClient+Token.swift`, and the credential attachment in the shared `request` method in `Sources/ContainerizationOCI/Client/RegistryClient.swift`. The SSRF occurs whether or not the client holds credentials, because the token request needs none. Credential disclosure needs a client configured with an `Authentication`. **Not affected:** `LocalOCILayoutClient`, which reads a local OCI layout and makes no network request. ## Mitigations 1. Upgrade to the patched version. 2. Remove the saved credentials for every registry you do not operate, and authenticate only against registries you control. This removes the credential disclosure. It does not remove the SSRF. 3. Deny the host egress to link-local and private address ranges, so that the client cannot reach a realm that names an internal service: `169.254.0.0/16`, `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`. 4. Never configure a registry as insecure, so that an attacker in a privileged network position cannot inject the challenge. This removes the on-path variant only. It does not stop a hostile registry. A registry reached over `https` **does not** mitigate this on its own. The client validates neither the realm host nor the realm scheme, whatever scheme the registry itself uses. Storing the credentials in the macOS keychain **does not** mitigate this. The client reads the credentials and sends them. ## Verifying whether you are affected Read the challenge that each registry advertises, then look for its realm host in your egress records. 1. Request the version endpoint and print the response headers. This changes no state: ``` curl -sS -D - -o /dev/null https://<registry>/v2/ | grep -i www-authenticate ``` 2. Compare the `realm` host against `<registry>`. An unpatched client sends the cred
- Severity from
- GitHub (reviewed advisory)