AvUSDMinting Manual Review Findings

AUM-01M: Potential Cross-User Interference

Type	Severity	Location
Logical Fault		AvUSDMinting.sol:L189, L220, L252

Description:

The AvUSDMinting::_deduplicateOrder function which is meant to prevent signature replay attacks will utilize the order's benefactor as the key regardless of the actual signer of the payload, and will not differentiate between redemptions and mint operations.

As a result, the interactions of a delegated signer will interfere with the interactions of the benefactor themselves as well as other delegated signers of the same benefactor.

Impact:

A temporary Denial-of-Service might result from multiple authorized parties of a benefactor interacting with the AvUSDMinting contract.

Example:

Copy
238/**
239 * @notice Redeem stablecoins for assets
240 * @param order struct containing order details and confirmation from server
241 * @param signature signature of the taker
242 */
243function redeem(Order calldata order, Signature calldata signature)
244  external
245  override
246  nonReentrant
247  onlyRole(REDEEMER_ROLE)
248  belowMaxRedeemPerBlock(order.avusd_amount)
249{
250  if (order.order_type != OrderType.REDEEM) revert InvalidOrder();
251  verifyOrder(order, signature);
252  _deduplicateOrder(order.benefactor, order.nonce);
253  // Add to the redeemed amount in this block
254  redeemedPerBlock[block.number] += order.avusd_amount;
255  avusd.burnFrom(order.benefactor, order.avusd_amount);
256  _transferToBeneficiary(order.beneficiary, order.collateral_asset, order.collateral_amount);
257  emit Redeem(
258    msg.sender,
259    order.benefactor,
260    order.beneficiary,
261    order.collateral_asset,
262    order.collateral_amount,
263    order.avusd_amount
264  );
265}

Recommendation:

We advise the actual signer to be utilized for signature invalidation, preventing interference between authorized parties of the same benefactor.

Alleviation:

The Avant Protocol team thoroughly evaluated the ramifications of the exhibit's issue and proceeded to acknowledge it as they consider it an unlikely scenario when we factor in that the functions involved are invoked by privileged roles.

As the maximum impact has been correctly assessed by the Avant Protocol team as a temporary DoS that can be circumvented by re-submitting the transaction with a different nonce, we consider this exhibit safely acknowledged.

AUM-02M: Insecure Nonce Validation

Type	Severity	Location
Mathematical Operations		AvUSDMinting.sol:L444

Description:

The AvUSDMinting::verifyNonce function will improperly validate a nonce value as it will only check that it is non-zero, permitting values that would result in a casting overflow to occur.

Impact:

Improper nonce values can be utilized, including a nonce value that would be treated as 0 by the arithmetic statements of the AvUSDMinting::verifyNonce function.

Example:

Copy
443function verifyNonce(address sender, uint256 nonce) public view override returns (uint256, uint256, uint256) {
444  if (nonce == 0) revert InvalidNonce();
445  uint256 invalidatorSlot = uint64(nonce) >> 8;
446  uint256 invalidatorBit = 1 << uint8(nonce);
447  uint256 invalidator = _orderBitmaps[sender][invalidatorSlot];
448  if (invalidator & invalidatorBit != 0) revert InvalidNonce();
449
450  return (invalidatorSlot, invalidator, invalidatorBit);
451}

Recommendation:

We advise the nonce value to be restricted to at most type(uint64).max, preventing a nonce of 0 from being validated via a value that exceeds the uint64 value space.

Alleviation (7a667d295d):

An additional condition has been introduced to the initial if-revert check within the AvUSDMinting::verifyNonce function that will cause the code to revert if the nonce exceeds or matches the maximum value of a uint64 variable.

While the equality case is unnecessary as 0xFF..FF in its uint64 form would be properly processed by the code, we consider the original exhibit fully alleviated.

Alleviation (93419dea95):

The Avant Protocol team proceeded with updating the conditional to permit a value of type(uint64).max, alleviating this exhibit in full.

AUM-03M: Non-Granular Signature Delegation

Type	Severity	Location
Logical Fault		AvUSDMinting.sol:L283-L287, L289-L296, L298-L302

Description:

The signature delegation system of the AvUSDMinting contract does not differentiate between mint and redeem requests, and additionally permits any asset to be utilized as part of a mint request.

Impact:

We do not consider the present delegation system secure as it permits a delegated party to access all approved assets of a delegator as well as permit them to perform both mint operations and redemptions.

Example:

Copy
283/// @notice Enables smart contracts to delegate an address for signing
284function setDelegatedSigner(address _delegateTo) external {
285  delegatedSigner[_delegateTo][msg.sender] = DelegatedSignerStatus.PENDING;
286  emit DelegatedSignerInitiated(_delegateTo, msg.sender);
287}
288
289/// @notice The delegated address to confirm delegation
290function confirmDelegatedSigner(address _delegatedBy) external {
291  if (delegatedSigner[msg.sender][_delegatedBy] != DelegatedSignerStatus.PENDING) {
292    revert DelegationNotInitiated();
293  }
294  delegatedSigner[msg.sender][_delegatedBy] = DelegatedSignerStatus.ACCEPTED;
295  emit DelegatedSignerAdded(msg.sender, _delegatedBy);
296}
297
298/// @notice Enables smart contracts to undelegate an address for signing
299function removeDelegatedSigner(address _removedSigner) external {
300  delegatedSigner[_removedSigner][msg.sender] = DelegatedSignerStatus.REJECTED;
301  emit DelegatedSignerRemoved(_removedSigner, msg.sender);
302}

Recommendation:

We advise the signature delegation system to be revised, introducing support for what type of action is actually permitted to be delegated as well as what assets can be used by the delegated party in case of a mint operation.

Alleviation:

The Avant Protocol team evaluated this exhibit in depth and opted to acknowledge it. They do not consider the heightened granularity as being necessary for their business use case, and believe that the privileged interactions involved with the mint and redeem requests are sufficient.

As a clarification, the exhibit's any asset statement referenced the fact that a user is not able to make delegations per-asset rather than the code permitting any asset to be used with it.

Given that the current code aligns with the business requirements of the Avant Protocol team, we consider this exhibit to be safely acknowledged.