DataPointRegistry Manual Review Findings

DPR-01M: Inexistent Revocation of Administrators

Type	Severity	Location
Logical Fault		DataPointRegistry.sol:L47-L54

Description:

The DataPointRegistry::transferOwnership function permits a particular DataPoint to be transferred to a new owner, however, the DataPoint will retain all original authorized administrators.

This represents a flaw in the transfer process as the recipient of the DataPoint cannot react during its acceptance, requiring two separate blockchain blocks for a new owner to remove the administrators they wish.

Impact:

The DataPointRegistry::transferOwnership function necessitates two distinct interactions across two different blocks for a transfer to be accompanied with administrator removal which we consider an approach prone to errors and exploitation.

Example:

Copy
47/// @inheritdoc IDataPointRegistry
48function transferOwnership(DataPoint dp, address newOwner) external {
49    DPAccessData storage dpd = _accessData[dp];
50    address currentOwner = dpd.owner;
51    if (msg.sender != currentOwner) revert InvalidDataPointOwner(dp, msg.sender);
52    dpd.owner = newOwner;
53    emit DataPointOwnershipTransferred(dp, currentOwner, newOwner);
54}

Recommendation:

We advise the system to revoke all previous administrators during a transfer by using a nonce system or a similar approach, ensuring that the DataPoint is transferred in a fresh state and a rogue administrator cannot affect it after it has exchanged hands.

Alleviation:

The system was updated to instead remove the previous administrators one-by-one whenever an ownership transfer occurs.

While this approach resolves the described issue, it might breach the block's gas limit as the number of administrators increases and is generally ill-advised due to the associated gas concerns.

We advise a proper nonce system or similar mechanism to be employed, permitting the administrators to be refreshed by updating a single data entry optimally and in a scalable manner.

The Nexera team evaluated our follow-up recommendation and assessed the actual gas needs that the system would have under reasonable operating assumptions, coming to the conclusion that the block gas limit is unlikely to be breached in a production scenario.

As such, we consider this exhibit adequately addressed.