Summary

Registry v0.8 introduced a new authorization utility. Permission calculation related to Person Role management was rewritten to incorrectly allow certain operations on any CO Person Role for any CO Person that a COU Administrator could manage, instead of just the CO Person Roles in that COU Administrator's COU.

Severity

The severity of this issue is medium, as only COU Administrators can take advantage of this exploit.

Exposure

The exposure will generally be low to medium, as this advisory only meaningfully affects deployments with COU Administrators, and COU Administrators are generally trusted individuals.

Recommended Mitigation

Deployments without COU Administrators need not take any action, though should plan an upgrade as soon as plausible in case COU Administrators are added later.

Deployments with COU Administrators should immediately upgrade to Registry v4.3.0, or to develop commit 103c995 or later.

Deployments may also perform an audit, as described in Discussion, below.

Alternate Mitigations

Deployments may alternately disable any COU Administrator privileges until an upgrade can be performed.

Discussion

COU Administrators generally have permission to edit CO Person Role records only for those Roles in the COU that they manage. (COU Administrators can view other Roles however.) Registry v0.8 refactored permission calculation into the RoleComponent. In doing so, the logic for editing a Person Role was incorrectly implemented as granting permission as long as the COU Admin was an Admin for any CO Person Role for the CO Person, not just CO Person Roles in the same COU.

Because all changes to Registry data are recorded, it is possible to determine if any CO Person Role records were modified by unauthorized COU Administrators, though the techniques for doing so may require some effort, depending on the size of the database. Changes are visible in two ways:

  1. Human readable transaction history is available via the HistoryRecords attached to the CO Person and CO Person Role, and the CO Person ID of the person who made the change is recorded with this history.
  2. Changes to the database tables are made via copy on write, and the authenticated identifier of the user is recorded with the change.

See Registry History and Changelogs for more information. It is possible to correlate this information against the set of COU Administrators and the COUs and CO Person Roles they can manage, though changes to the set of COU Administrators over time may also need to be accounted for.

References

  • CO-2698


  • No labels