There are two custom libraries LibSiloPermit.sol
and LibTokenPermit.sol
that implement permit functions, which are basically gasless approvals via signatures, an owner sets allowance to a spender via signature. However these signatures doesn't account for chain forks.
As can be seen the chain id is included in the "domain separator":
However it's not included in the signed data as part of the permit call:
So in case of a chain fork after deployment, the signed message may still be valid on both forks.
Here is a scenario:
The approval is included in an upcoming hard fork that will separate the community.
Some users stay on the old chain, some on the new chain.
On the new chain Alice approves Bob to spend some tokens via permit()
.
Bob being on both chains, replays the permit()
call on the old chain and this allows him to steal value.
Impact: High, as there is a chance for a potential theft
Likelihood: Low, as it requires a fork to occur
Overall: Medium
Manual Review
Condsider dynamically computing the chain id inside the functions and then add it in the signature schemas:
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.