https://bugzilla.suse.com/show_bug.cgi?id=1198683 Bug ID: 1198683 Summary: VUL-0: CVE-2022-1245: keycloak: Privilege escalation vulnerability on Token Exchange Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other URL: https://smash.suse.de/issue/329495/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: fstrba@suse.com Reporter: cathy.hu@suse.com QA Contact: security-team@suse.de Found By: Security Response Team Blocker: --- rh#2071036 Keycloak supports OAuth2 Token Exchange an OAuth2 specification that allows clients to exchange tokens for delegation and impersonation purposes. In Keycloak, the support for token exchange is marked as a technology preview feature and disabled by default. When the feature is enabled, any client application holding a valid access token is able to exchange tokens for any other target client by authenticating as the target client. This problem is especially problematic when the credentials used to authenticate to the token endpoint is for a public client because the authentication for these clients is solely based on the client_id (public information). The vulnerability found allows a malicious client to exchange tokens for another client and then use the new token to access services that otherwise it should not have access. The expected behavior should be that clients (regardless of public or confidential) should only be able to exchange tokens for themselves, and using a subject_token issued to another client should be prohibited if there is no permission granted. To reproduce the issue: 1. The preview feature token-exchange must be enabled. Given 1 user, 1 public or secret client (client-third-party) in which an attacker has access to, and 1 public client (client-secure) in the same realm. 2. Assume client-third-party is a restricted client and has no realm or resource access. The public client, client-secure, has access to an API secured with a resource access role. 3. Authenticate as a user with the client-third-party client and store the user's access token 4. Use the access token in a token exchange request. Specify client-secure as client_id, the user's access token as subject_token and do not add an audience parameter. 5. The result of the token exchange will be an access token, and potentially a refresh token, with all access which only the client-secure should have access to. Notice that in order to reproduce this, you do not have to configure any permissions for the client. Neither do you have to enable the admin fine grained permissions feature. References: https://bugzilla.redhat.com/show_bug.cgi?id=2071036 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1245 -- You are receiving this mail because: You are on the CC list for the bug.