More details on security fix in 15.1.1

[Stian Thorgersen]

CVE and security advisory is now ready for the issue that was fixed in Keycloak 15.1.1:

https://github.com/keycloak/keycloak/security/advisories/GHSA-83x4-9cwr-5487

The list of issues fixed in the release has also been updated to include this issue:

https://github.com/issues?q=is%3Aissue+user%3Akeycloak+is%3Aclosed+milestone%3A15.1.1

[C R]

Thank you, Stian. The heads-up is certainly appreciated!

CR

> --
> You received this message because you are subscribed to the Google Groups "Keycloak User" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/CAJgngAfExvDK9GnwxVbsdQS0hZQ8Q5THJSkNYuR%3DuU14nJJA5Q%40mail.gmail.com.

[benjam...@gmail.com]

Can the security issue be temporarily mitigated in < 15.1.1 by blocking all external access to /auth/admin/*?

[Stian Thorgersen]

As long as you don't have anyone on the inside of your network that can abuse it I would say that is a decent temporary mitigation.

--

You received this message because you are subscribed to the Google Groups "Keycloak User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/0566df42-4eca-4a6a-8f1e-02a1219dd1a5n%40googlegroups.com.

[Welton Torres]

Did this vulnerability allow group membership changes for the newly created user?

[Jan Garaj]

I have zero trust approach also for internal network. Can the security issue be temporily mitigated in <15.1.1 by blocking POST requests to /{realm}/users Admin REST API resource? We use LDAP federation, so I don't see any problem with users functionality - they are not created via admin REST API, but via LDAP synchronization.

Thanks.

[Christophe Balczunas]

Is there an official score available, independent from Red Hat's Single Sign on 7.3.5 product? (which is 8.3 here https://access.redhat.com/security/cve/CVE-2021-4133#cve-cvss-v3).

The rationale behind my question is to assess the risk accurately for Keycloak server itself.   Say I'm in situation where there are existing installations of my product that use Keycloak 12.0.4 (vulnerable).  Next cycle, we'll update to 16.1, but atm it's not practical to back port 16.1 related integration changes, client libraries impact etc.   Also not practical to disable the rest api since I believe the admin console uses it for local users which in my case we need, correct?

So I'm left naively wondering: ok, it's bad, one john smith can create another john smith2 that shouldn't be there.   But john smith2 cannot get any roles assigned to him (I am assuming, else it would have been called out in the advisory) so presumably cannot do much with his new ID.   So there is not direct elevation of privilege here, am I correct?   Not without some compound layered attack with another vulnerability (which to be safe we should presume could exist, but there is no evidence of that this time, is there?).

Perhaps that is an actual practical issue though: DooS attack by blasting Keycloak with create user requests (bloating the backend db basically)?

Thanks for any additional factual info (or even opinion) you may have on the topic!