The Settings section of the administration area allows administrators and operators to change the secrets that establish trust in the single-sign on process, namely the SAML certificate and corresponding private key, and the OIDC signing key.
Such secrets can be also retrieved from the administration area, accessible to operators and administrators. If an administrator sets up such private keys, a different user with appropriate permissions (e.g., an operator) can subsequently obtain them in plaintext simply by browsing to the administration area, as shown in the following screenshot:
This is due to the fact that the fields oidc_signing_key and saml_key defined in the Setting model are both rendered by the corresponding textareas in the setting templates without checking whether the keys were originally set by the current user or not, as shown in the following code snippets (saml.html.erb and openid_connect.html.erb respectively).
<textarea name="setting[saml_key]" class="form-control"><%=Setting.saml_key %></textarea>
<textarea name="setting[oidc_signing_key]" class="form-control"><%= Setting.oidc_signing_key %></textarea>
Impact
Impact is limited to highly-privileged users. In case an operator or administrator account is compromised, or in case of a rogue operator or administrator, the private key could silently be exfiltrated, without any trace in the audit log. Subsequently, administrator and operators may impersonate EyeDP from the point of view of the service providers.
Patches
This issue is resolved in PR 385. Users should upgrade to the latest commit on main or to a 1.0.0 or later release.
Workarounds
None
For more information
If you have any questions or comments about this advisory:
The Settings section of the administration area allows administrators and operators to change the secrets that establish trust in the single-sign on process, namely the SAML certificate and corresponding private key, and the OIDC signing key.
Such secrets can be also retrieved from the administration area, accessible to operators and administrators. If an administrator sets up such private keys, a different user with appropriate permissions (e.g., an operator) can subsequently obtain them in plaintext simply by browsing to the administration area, as shown in the following screenshot:
This is due to the fact that the fields oidc_signing_key and saml_key defined in the Setting model are both rendered by the corresponding textareas in the setting templates without checking whether the keys were originally set by the current user or not, as shown in the following code snippets (saml.html.erb and openid_connect.html.erb respectively).
Impact
Impact is limited to highly-privileged users. In case an operator or administrator account is compromised, or in case of a rogue operator or administrator, the private key could silently be exfiltrated, without any trace in the audit log. Subsequently, administrator and operators may impersonate EyeDP from the point of view of the service providers.
Patches
This issue is resolved in PR 385. Users should upgrade to the latest commit on main or to a 1.0.0 or later release.
Workarounds
None
For more information
If you have any questions or comments about this advisory: