Preface
In practice, achieving an index value greater than 2 ** 127 + 1 is infeasible by minting in unit increments, so deployment of this contract as is should be safe. The suggestion below is mostly for logical soundness, however users who make modifications to the prototype by replacing the base type incrementer with custom id's should be made aware, and perhaps guards should be put in place.
Expected Behavior
In contract {ERC1155MixedFungibleMintable}, all _type values in the range supported by its integer type uint256 can be created and accessed without clashes and access control insecurity.
Actual Behavior
The current demonstration code runs the risk of calls reduced to the same base _type for the index range between 2**127 and 2**256 - 1, where in a simplified 8-bit demonstration of left-shifted index values masked by the TYPE_NF_MASK:
0001 0001 << 4 | 1000 0000 and 0000 0001 << 4 | 1000 0000
result in the sender address being overwritten in the create() call on L137 of ERC1155MixedFungibleMintable
In addition, any nonce value where the lower half order of bits falls between xxxx 1000 and xxxx 1111 will clash with values ranging in xxxx 0000 and xxxx 0111.
As such, regarding these two attack vectors, the nonce value should not exceed 2 ** (256/2 - 1) - 1.
Similarly, maxIndex should not exceed 2 ** (128) - 1.
Suggestion
Limit _type to a supported uint type less than 2 ** 127, i.e. uint120 where compiler ^0.8 can handle overflow checks, or add validation logic to revert index values greater than that safe value, or utilize recent feature of User-Defined Types. A more expensive and unnecessarily complicated construction would be to create and manipulate 2 word custom integers, e.g., a Uint512Lib custom library.
Preface
In practice, achieving an index value greater than 2 ** 127 + 1 is infeasible by minting in unit increments, so deployment of this contract as is should be safe. The suggestion below is mostly for logical soundness, however users who make modifications to the prototype by replacing the base type incrementer with custom id's should be made aware, and perhaps guards should be put in place.
Expected Behavior
In contract {ERC1155MixedFungibleMintable}, all
_typevalues in the range supported by its integer typeuint256can be created and accessed without clashes and access control insecurity.Actual Behavior
The current demonstration code runs the risk of calls reduced to the same base
_typefor theindexrange between2**127and2**256 - 1, where in a simplified 8-bit demonstration of left-shiftedindexvalues masked by theTYPE_NF_MASK:0001 0001 << 4 | 1000 0000and0000 0001 << 4 | 1000 0000result in the sender address being overwritten in the
create()call on L137 of ERC1155MixedFungibleMintableIn addition, any
noncevalue where the lower half order of bits falls betweenxxxx 1000andxxxx 1111will clash with values ranging inxxxx 0000andxxxx 0111.As such, regarding these two attack vectors, the nonce value should not exceed
2 ** (256/2 - 1) - 1.Similarly,
maxIndexshould not exceed2 ** (128) - 1.Suggestion
Limit
_typeto a supporteduinttype less than 2 ** 127, i.e.uint120where compiler^0.8can handle overflow checks, or add validation logic to revert index values greater than that safe value, or utilize recent feature of User-Defined Types. A more expensive and unnecessarily complicated construction would be to create and manipulate 2 word custom integers, e.g., aUint512Libcustom library.