Issue summary
In EJBCA versions prior to EJBCA 9.3.3, removing an administrator from their administrator role does not fully invalidate authentication caches.
In clustered EJBCA environments, when an administrator is removed from a role, then currently active sessions are not invalidated on the other nodes. This means that the removed administrator can still access EJBCA, for a limited period of time, as long as their TLS session from their browser remains active.
Who is potentially affected?
Installations where multiple EJBCA nodes share the same database.
Who is not affected?
- Single-node EJBCA installations.
- EJBCA installations where each CA node uses a separate database.
- EJBCA instances where EJBCA is always restarted after role changes.
Severity
Keyfactor rates the issue as having a severity level of medium as the circumstances under which this vulnerability can occur are unlikely, as well as time-limited.
Vulnerability Vectors
Incorrect caching of authentication.
How to check if you are affected
You may be affected if you had to remove the access of an administrator while running a vulnerable version (<9.3.3). You can check the Audit Log to see if any revoked administrators have accessed EJBCA.
Mitigation
Upgrade to EJBCA 9.3.3 or later.
Alternatively, prior to upgrade:
- Access rules of a role are not affected by the issue. Therefore, instead of removing administrators from their role, it is possible to remove all access rules from the role. Any administrators who need to retain access should first be moved to another role.
- Alternatively, restart EJBCA after removing any role members.
For available deployment options and associated versions, refer to Supported Versions.
Additional information
Should you have any additional questions, please reach out to support@keyfactor.com.
Comments
Article is closed for comments.