Headline
CVE-2023-1584: Encrypt OIDC session cookie value by default by sberyozkin · Pull Request #32192 · quarkusio/quarkus
A flaw was found in Quarkus. Quarkus OIDC can leak both ID and access tokens in the authorization code flow when an insecure HTTP protocol is used, which can allow attackers to access sensitive user data directly from the ID token or by using the access token to access user data from OIDC provider services. Please note that passwords are not stored in access tokens.
Hi @cescoffier
It seems that each token is encrypted individually. Why not encrypt the whole content of the cookie?
Good question, thanks. This is done now in the PR by default, let me clarify, there was too much text in the description, copying the related part here:
- Optimizes the way the tokens are encrypted, right now it is quite sub-optimal, where up to 3 JWE encryptions will be done and 3 cipher texts saved in the session cookie - instead, now only a single encryption is done on all the 3 tokens concatenated together. For example, now, instead of q_session=encrypted_id_token|encrypted_access_token|encrypted_refresh_token you will see q_session=encrypted(id_token_access_token_refresh_token).
You can see it confirmed for example, here.
The session cookie format is q_session=IDTOKEN|ACCESSTOKEN|REFRESHTOKEN, and you are right, on main, each of these tokens is encrypted individually, but like you say, with this PR, the whole cookie value is now encrypted.
What may be a bit confusing is that we have options to split the session cookie, (split_tokens=true), so we’d have 3 cookies in such cases:
q_session=IDTOKEN
q_session_at=ACCESSTOKEN
q_session_rt=REFRESHTOKEN
This has been done to support the situations where a single session cookie size exceeds 4096 bytes - if the tokens are in JWT format, their size can be massive, some providers (and I specifically recall issues with Azure) can put a lot of claims into for ex ID token, and when it is all signed and base64url encoded to have JWT, the size can be big. So if 3 tokens concatentated together exceed 4096 limit, browsers can lose them.
So for such cases, a split option is possible, where each of these tokens will be saved in their own cookie, in which case, in case of the encryption, indeed, every token will be encrypted individually.
But the default, out of the box option, will now have the whole session cookie value, with all 3 tokens, encrypted once.
Related news
Red Hat Security Advisory 2023-7653-03 - An update to the images for Red Hat Integration - Service Registry is now available from the Red Hat Container Catalog. The purpose of this text-only errata is to inform you about the security issues fixed in this release. Issues addressed include bypass and denial of service vulnerabilities.
A flaw was found in Quarkus. Quarkus OIDC can leak both ID and access tokens in the authorization code flow when an insecure HTTP protocol is used, which can allow attackers to access sensitive user data directly from the ID token or by using the access token to access user data from OIDC provider services. Please note that passwords are not stored in access tokens.
A vulnerability was found in quarkus-core. This vulnerability occurs because the TLS protocol configured with quarkus.http.ssl.protocols is not enforced, and the client can force the selection of the weaker supported TLS protocol.
An update is now available for Red Hat build of Quarkus. Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability. For more information, see the CVE links in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2022-45787: A flaw was found in Apache James's Mime4j TempFileStorageProvider class, where it may set improper permissions when utilizing temporary files. This flaw allows a locally authorized attacker to access information outside their intended permissions. * CVE-2023-0481: In RestEasy Reactive implementation of Quarkus the insecure File.createTempFi...