_DOMAIN_SEPARATOR is not updated, when name of token is changed #404
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
duplicate-146
edited-by-warden
satisfactory
satisfies C4 submission criteria; eligible for awards
sufficient quality report
This report is of sufficient quality
Lines of code
https://github.com/code-423n4/2023-09-centrifuge/blob/main/src/token/ERC20.sol#L84
https://github.com/code-423n4/2023-09-centrifuge/blob/main/src/PoolManager.sol#L223
Vulnerability details
Impact
_DOMAIN_SEPARATOR is not updated, when name of token is changed
Proof of Concept
This is similar to the one that i have already submited. However, i believe that this is separate issue, because in case if first one is fixed, this one still remains. While first bug is about wrong initialization, this one is about updating metadata of contract which is a part of functionality of protocol.
Here is similar issue on c4.
According to the EIP-712 in case if name, version or any other fields in the _DOMAIN_SEPARATOR is changed, then all previous signatures should not be valid anymore.
Tranche token metadata can be changed if needed. This is handled by
PoolManager.updateTrancheTokenMetadata
function. This function will changename
field, which is part of_DOMAIN_SEPARATOR
.The problem is that after changing the name field,
_DOMAIN_SEPARATOR
will not be recalculated, which means that all signatures that were signed before will be still valid. Also as i have described in another report, user's will see that Tranche token name is not same as in the domain separator that they should sign, so users will likely reject signing. And people who will craft messages themselves will use real updated name to create domain separator, so it will not match and permit will revert.Tools Used
VsCode
Recommended Mitigation Steps
When you update
name
, then recalculate domain separator.Assessed type
Error
The text was updated successfully, but these errors were encountered: