Closed code423n4 closed 1 year ago
0xA5DF marked the issue as duplicate of #571
0xA5DF marked the issue as duplicate of #132
hansfriese changed the severity to QA (Quality Assurance)
hansfriese marked the issue as grade-b
Hi @hansfriese , can you explain why this issue (and other duplicates) was downgraded? The griefing attack is very likely to happen as it is easy to perform, breaking the entire restructuring functionality , which falls under the function of the protocol or its availability could be impacted
Medium category of the docs. On top of that the mitigation suggested would get rid of the issue entirely.
Lines of code
https://github.com/code-423n4/2023-04-frankencoin/blob/1022cb106919fba963a89205d3b90bf62543f68f/contracts/Equity.sol#L310
Vulnerability details
Equity.restructureCapTable
allows qualified FPS holders to restructure the system, that is: burning shares of other holders that did not participate in putting equity above water.The issue is that the process cannot be done atomically: the "brave souls" have to call
restructureCapTable()
first, then donatezchf
.Impact
A malicious shareholder (holding more than 3% of the totalShares) can front run the call to
restructureCapTable()
by legitimate users ready to givezchf
, callingrestructureCapTable()
to burn the shares of the "brave souls" that made the initial call.Note this attack is even more likely that at this stage, the malicious shareholder have nothing to lose: their shares were worth nothing (because of equity being underwater) and they were about to be "wiped out" by the legitimate users call to
restructureCapTable()
.Tools Used
Manual Analysis
Mitigation
To avoid this griefing attack, a solution is to make the bootstrapping process atomic: the callers of
restructureCapTable()
will transferzchf
in the call