SellerBase Manual Review Findings

SBE-01M: Restrictive Deployment of Voucher Clone

Type	Severity	Location
Logical Fault		SellerBase.sol:L99, L172

Description:

The SellerBase::createSellerInternal function will deploy a BosonVoucher instance utilizing the create2 deployment methodology and a salt derived from the sender as well as an external ID value.

This external ID value is hard-coded to an empty string ("") during the creation of a seller, meaning that its sender can deploy a BosonVoucher once. This type of functionality significantly restricts the flexibility offered to users as well as integrators of the Boson Protocol system; especially automated seller deployers.

Impact:

The impact of this change may be severe depending on the adoption of the Boson Protocol system and how many automated smart contracts utilize the SellerBase::createSellerInternal workflows (such as SellerHandlerFacet::createSeller or the OrchestrationHandlerFacet1 contract's createSeller prefixed functions).

Example:

Copy
98// Create clone and store its address cloneAddress
99address voucherCloneAddress = cloneBosonVoucher(sellerId, 0, sender, _seller.assistant, _voucherInitValues, "");

Recommendation:

We advise the code to re-evaluate its approach in regard to create2 deployments, potentially utilizing two types of "ID" values for the salt generation; one for the "upper-level" BosonVoucher seller ID deployment and one "lower-level" for each collection deployment.

Alleviation (2b9f60b6c3323fd234b570089ceff924cdb5851c):

A specialized collection-level salt is now utilized that can be "reserved" by an address and utilized for the deployment of a collection-level Boson Voucher.

As the codebase has been significantly refactored to accommodate for this change and it is possible to have multiple Boson Voucher deployments depending on the collections desired, we consider this exhibit fully alleviated.

SBE-02M: Incorrect Association of Seller ID

Type	Severity	Location
Logical Fault		SellerBase.sol:L145

Description:

The SellerBase::createSellerInternal function will permanently associate a seller ID with its creator even if the voucher generated from it is transferred.

As such, the new owner will be able to deploy collection-level BosonVoucher instances utilizing salt values that would have been generated by the original deployer.

Impact:

As the creator of a seller ID is permanently associated with their voucher, the new owner of a voucher will be able to "hijack" the original owner's collection-level Boson Voucher deployments by utilizing the same external ID.

Additionally, a particular user may have multiple collections deployed on chain A and none deployed on chain B; a user who legitimately acquires ownership of the BosonVoucher on chain B will be able to deploy collection-level BosonVoucher instances on the same addresses as chain A even if the original owner did not deploy them.

Example:

Copy
145_lookups.sellerCreator[_seller.id] = msgSender();

Recommendation:

We advise this issue to be alleviated in tandem with the "Restrictive Deployment of Voucher Clone" exhibit as it relates to how salt values are generated within SellerBase::cloneBosonVoucher.

Alleviation (2b9f60b6c3):

The code was updated to utilize a seller ID salt system that is also update-able, meaning that it is possible to disassociate a seller ID with its previous salt and update it to point to a new one.

We would like to note that we consider this exhibit partially alleviated as the seller salt that was previously "reserved" should remain so as it has been used in the past. To address this, we advise the false assignment in the newly declared SellerHandlerFacet::updateSellerSalt function to be omitted.

Alleviation (584e7d054c):

After extensive discussions with the Boson Protocol team, we concluded that the risk arising from salt re-use is negligible and the flexibility permitted by it far outweighs it.

As such, we consider this exhibit fully alleviated per the original remediation.