🔸Examples
Last updated
Last updated
Good writing skills are important to communicate complex ideas, ensuring that the reader fully understands the vulnerability's significance and urgency. Below we provide two examples to follow as a guideline when submitting Findings.
A good finding report clearly explains
What is the issue.
How / Why is it happening.
Where exactly is the vulnerable code located and which logic does it connect to.
How to reproduce it with a Proof Of Concept.
How it can be remediated.
In the image below you will find a finding submission by cantina.xyz/u/cmichel. Lets dissect why this is a good finding and why you should follow this standard.
Clearly describes what the issue.
The
supply
andwithdraw
functions can increase the supply share price (totalSupplyAssets / totalSupplyShares
). If a depositor uses theshares
parameter insupply
to specify how many assets they want to supply they can be tricked into supplying more assets than they wanted. It's easy to inflate the supply share price by 100x through a combination of a single supply of 100 assets and then withdrawing all shares without receiving any assets in return.
Clearly describes why is it happening.
The reason is that in
withdraw
we compute theassets
to be received asassets = shares.toAssetsUp(market[id].totalSupplyAssets, market[id].totalSupplyShares);
. Note thatassets
can be zero and thewithdraw
essentially becomes a pureburn
function.
Clearly points to the vulnerable line using the Highlighting code feature.
Provides a Proof Of Concept for anyone to reproduce and verify the vulnerability.
Provides a remediation for the client.
Suppliers should use the
assets
parameter instead ofshares
whenever possible. In the other cases whereshares
must be used, they need to make sure to only approve the max amount they want to spend. Alternatively, consider adding a slippage parametermaxAssets
that is the max amount of assets that can be supplied and transferred from the user. This attack of inflating the supply share price is especially possible when there are only few shares minted, i.e., at market creation or when an attacker / contracts holds the majority of shares that can be redeemed.
For Competitions, please use the Detailed template when submitting a finding.
The finding below is an example of a bad finding submission.
The description is generic, nonsensical because it shows lack of understanding of the protocol, does not clearly state the exact problem nor why is it happening.
It does not point to the lines of code affected.
It does not provide a Proof Of Concept.