From 76b42459406e7ea8e9dc35af7a1339a6927096f4 Mon Sep 17 00:00:00 2001 From: "advisory-database[bot]" <45398580+advisory-database[bot]@users.noreply.github.com> Date: Wed, 20 Dec 2023 17:56:24 +0000 Subject: [PATCH] Publish GHSA-9wgg-m99q-hhfc --- .../2023/12/GHSA-9wgg-m99q-hhfc/GHSA-9wgg-m99q-hhfc.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/advisories/github-reviewed/2023/12/GHSA-9wgg-m99q-hhfc/GHSA-9wgg-m99q-hhfc.json b/advisories/github-reviewed/2023/12/GHSA-9wgg-m99q-hhfc/GHSA-9wgg-m99q-hhfc.json index b3d829b9624..a81b9242c4e 100644 --- a/advisories/github-reviewed/2023/12/GHSA-9wgg-m99q-hhfc/GHSA-9wgg-m99q-hhfc.json +++ b/advisories/github-reviewed/2023/12/GHSA-9wgg-m99q-hhfc/GHSA-9wgg-m99q-hhfc.json @@ -1,13 +1,13 @@ { "schema_version": "1.4.0", "id": "GHSA-9wgg-m99q-hhfc", - "modified": "2023-12-19T23:12:03Z", + "modified": "2023-12-20T17:54:54Z", "published": "2023-12-19T23:12:03Z", "aliases": [ ], "summary": "Expired tokens can be renewed without validating the account password", - "details": "### Impact\nIn versions of the proxy from `2022-09-05` onwards (since 8c874c2ff3d503ac20c7d32f46e08547fcb9e23f), expired authorisation tokens could be renewed automatically without checking their validity against the original account configuration (i.e., the password that was set up when first configuring the account).\n\nAn attacker with knowledge of valid account addresses and careful timing (i.e., attempting to log in during a period from 10 minutes prior to the token expiry time, but before a genuine login request is received) could use this issue to gain access to an account.\n\nThis issue is not a concern if you only use the proxy on a local device. It is also not an issue if you are using the O365 resource owner password credentials grant (ROPCG) flow.\n\nIf you use the proxy in a publicly-accessible setting (i.e., it is available from the internet or another network), you should upgrade to version [`2023-12-19`](https://github.com/simonrob/email-oauth2-proxy/releases/tag/2023-12-19) immediately.\n\n### Patches\n[Email OAuth 2.0 Proxy version `2023-12-19`](https://github.com/simonrob/email-oauth2-proxy/releases/tag/2023-12-19) fixes this issue.\n\n### Detecting unauthorised access\nIn most standard configurations (specifically, when not using the O365 client credentials grant (CCG) flow), unauthorised access will be revealed by the presence of an unexpected reauthorisation prompt from the proxy when attempting to log in with the correct password.\n\nIt is not possible to detect unauthorised access in O365 CCG mode except via AAD/Entra or other external logs. However, it is also worth reiterating that the CCG flow should never be used in a publicly-accessible context due to the significant and potentially dangerous account control it provides.", + "details": "### Impact\nIn versions of the proxy from `2022-09-05` onwards (since 8c874c2ff3d503ac20c7d32f46e08547fcb9e23f), expired OAuth 2.0 client credentials grant (CCG) flow authorisation tokens could be renewed automatically without checking their validity against the original account configuration (i.e., the password that was set up when first creating an account in the proxy).\n\nAn attacker with knowledge of valid account addresses and careful timing (specifically, attempting to log in during a period from 10 minutes prior to the token expiry time, but before a genuine login request is received) could use this issue to gain access to an account.\n\nThis issue is only a security concern if you use the proxy with the CCG flow and no additional account secret encryption (see below). If this is the case, it is particularly important to update if you use the proxy in a publicly-accessible setting (i.e., it is available from the internet or across a network). To fix the issue you should switch to version [`2023-12-19`](https://github.com/simonrob/email-oauth2-proxy/releases/tag/2023-12-19) or later of the proxy immediately.\n\nIf you use this flow, but have also set `encrypt_client_secret_on_first_use = True` *and* removed the original `client_secret` value from the proxy's configuration file then this issue is not a concern.\n\nFor all other use-cases (e.g., a normal interactive account authentication, or the ROPCG flow), this issue is also not a concern. However, it is always recommended as best practice to keep the proxy up-to-date.\n\n\n### Patches\n[Email OAuth 2.0 Proxy version `2023-12-19`](https://github.com/simonrob/email-oauth2-proxy/releases/tag/2023-12-19) (commit eaaa1a2e7a132bf0958dd2f99a749ad98e3212aa) fixes this issue.\n\n\n### Issue details\nBecause it was originally designed for use as an interactive, local-only service on a single device, the proxy automatically resets account access tokens if incorrect IMAP/POP/SMTP login details are provided. For public-facing deployments, the `delete_account_token_on_password_error` option is provided, and can be set to `False` to disable this behaviour, which would normally be only a nuisance, rather than a security risk.\n\nRegardless of this option's value, the proxy encrypts locally-stored tokens, and requires interactive re-authentication (or, with the resource owner password credentials grant (ROPCG) flow, the correct remote account password) to renew tokens if they expire or are reset. The proxy's token retrieval implementation was created with this interactive process in mind.\n\nThe CCG flow is an administrator-level method that grants broad access without user knowledge or consent – no user interaction (or remote account password) is ever required. From 8c874c2ff3d503ac20c7d32f46e08547fcb9e23f until the fix in eaaa1a2e7a132bf0958dd2f99a749ad98e3212aa, when CCG tokens neared their expiry date (or had already expired), and the original unencrypted `client_secret` value was available they were automatically reset, renewed and encrypted with the given login password, but without checking whether that password was actually able to decrypt the _existing_ token.\n\n\n### Detecting unauthorised access\nIf you do not use the OAuth 2.0 CCG flow (which is currently only known to be supported by O365), unauthorised account access was not possible.[^1] Attempts to exploit this flaw will be revealed in the same way as any other malicious access: an unexpected reauthorisation prompt from the proxy when trying to log in with the legitimate account details.\n\nWhen using the CCG flow, if you have set `delete_account_token_on_password_error = False`, unauthorised access will be revealed by the presence of an unexpected login failure from the proxy when attempting to log in with the correct password.\n\nIt you have not set this value, it is not possible to detect unauthorised access in O365 CCG mode except via AAD/Entra or other external logs. However, it is also worth reiterating that the CCG flow should never be used in a publicly-accessible context due to the significant and potentially dangerous account control it provides.\n\n[^1]: If you are using a provider that does not provide an OAuth 2.0 refresh token (or have configured your account's scope so that this is not present), it is possible to trigger the line of code that caused this issue, but there is no way to use it for account access because interactive authentication is still required.", "severity": [ { "type": "CVSS_V3",