00xSEV - An attacker can exploit VD address collisions using create2 to lock some liquidations and withdrawals in Maker protocol #63
Comments
github-actions
bot
added
Has Duplicates
|
1 comment(s) were left on this issue during the judging contest. Audittens commented:
|
|
The protocol team comments:
|
sherlock-admin2
changed the title
sherlock-admin2
added
Non-Reward
|
Escalate if https://github.com/sherlock-audit/2024-06-makerdao-endgame-judging/issues/64 is a medium this issue should be a medium as well.
but the cost of attack will decrease as shown in the report and the loss of fund have no upper side because user will keep lock voting power fund. function lock(uint256 wad) external {
require(block.number == hatchTrigger || block.number > hatchTrigger + HATCH_SIZE,
"VoteDelegate/no-lock-during-hatch");
gov.transferFrom(msg.sender, address(this), wad);
chief.lock(wad);
stake[msg.sender] += wad;
emit Lock(msg.sender, wad);
} |
You've created a valid escalation! To remove the escalation from consideration: Delete your comment. You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final. |
|
other evidence: issue #109 which is a duplicate of valid issue has the following the text:
and
I think as outlined by a lot of report, the attacker can approve the token allowance and then self-destruct so any fund that deposit into the contract can be transfered out and get stolen. |
|
The rules state that a valid duplicate must "Identify at least a Medium impact" (https://docs.sherlock.xyz/audits/judging/judging#ix.-duplication-rules). I can see that my issue (#63), which has the following impacts: has the same impact as and If impacts 1 and 2 are enough to be considered Medium, this issue should be valid. |
|
If this issue is valid, please also consider marking #37 as invalid since it lacks a sufficient proof of an attack path. No mentions about approves or selfdestruct, impossible to reproduce.
|
|
The |
|
I see how the problem with this report is the cost of the attack for #64. Hence, will provide my decision on this escalation, once the discussion on #64 is settled. |
|
#63 should not be considered a duplicate of #64 as it requires an attack that is harder and costlier to achieve than in #64 despite having a significantly lower impact than in #64.
|
|
Based on the discussion under #64 about the cost of the attack, I believe this finding is low-severity as well. Planning to reject the escalation and leave the issue as it is. |
|
Result: |
|
Escalations have been resolved successfully! Escalation status:
|
sherlock-admin4
added
the
Escalation Resolved
00xSEV
Medium
An attacker can exploit VD address collisions using create2 to lock some liquidations and withdrawals in Maker protocol
Summary
An attacker can use brute-force to find two private keys that create EOAs with the following properties:
eoa1.eoa1.Since a VD (VoteDelegate) address depends solely on
msg.sender. While this currently costs between $1.5 million and several million dollars (detailed in "Vulnerability Details"), the cost is decreasing, making the attack more feasible over time.The attacker can approve IOU tokens to an EOA,
attacker, and then create a VD. By transferring IOUs to another address, the attacker can lock liquidations and withdrawals for anyone using this VD.Vulnerability Detail
Examples of previous issues with the same root cause:
Summary
The current cost of this attack is less than $1.5 million with current prices.
An attacker can find a single address collision between (1) and (2) with a high probability of success using a meet-in-the-middle technique, a classic brute-force-based attack in cryptography:
The feasibility, detailed technique, and hardware requirements for finding a collision are well-documented:
The Bitcoin network hashrate has reached 6.5x10^20 hashes per second, taking only 31 minutes to achieve the necessary hashes. A fraction of this computing power can still find a collision within a reasonable timeframe.
Steps:
The attacker finds two private keys that generate EOAs with the following properties:
eoa1.eoa2, when used as a salt for VD creation, produces a VD with the same address aseoa1.Call
IOU.approve(attacker, max)fromeoa1.Call
voteDelegateFactory.create()fromeoa2:VD1.VD1address ==eoa1address.VD1retains the approvals given fromeoa1in step 2.Call
LSE.opento createLSUrn1.Call
LSE.lock(LSUrn1, 1000e18)to deposit funds.Call
LSE.draw(LSUrn1, attacker, maxPossible)to borrow the maximum amount.Call
LSE.selectVoteDelegate(LSUrn1, VD1)to transfer MKR tochiefand getIOUonVD1.Call
IOU.transferFrom(VD1, attacker, maxPossible).Now all liquidations will revert because
dog.bark=>LSClipper.kick=>LSE.onKick=>LSE._selectVoteDelegate=>VoteDelegateLike(prevVoteDelegate).free(wad);=>chief.free(wad);=>IOU.burnwill revert.The same is true for withdrawals of users who trusted this VD and delegated their funds to it, starting from
_selectVoteDelegate, which is called onfreeand will revert:hatby voting and gain full control of the protocol.Link to create2
Variations:
eoa1can be replaced with a contract created byeoa3. The address of the contract can be brute-forced in the same way aseoa1. The contract performs step 2 instead ofeoa1and self-destructs in the same transaction.eoa2in step 1, the attacker can use a contract. A brute-forced EOA creates a contract that will create a VD such that the VD address equalseoa1.Impact
The attacker can create non-liquidatable positions. All users who select the attacker's VD can lose their funds. All votes are permanently locked on the attacker's VD and can be used by the attacker for voting. Instead of
eoa2, a contract can be used to allow others to vote and sell voting power, similar to Curve bribing or other governance attacks.If the attacker could acquire a substantial amount of funds, they could select a
hatby voting and gain full control of the protocol.Code Snippet
test/ALockstakeEngine.solin the root project directory.test/ALockstakeEngine.sol
It is based on the
LockstakeEngine.t.solsetUpfunction:block.numberfor caching RPC callschiefandpollingcontracts from mainnetVoteDelegateFactoryTo see the diff, you can run
git diff. Note: all other functions exceptsetUpare removed from the file and the diff.git diff --no-index lockstake/test/LockstakeEngine.t.sol test/ALockstakeEngine.sol
remappings.txtto the root project directory.forge test --match-path test/ALSEH3.solfrom the root project directory.Tool used
Manual Review
Recommendation
salt, including usingmsg.sender.block.prevrandaowithmsg.sender. This approach will make finding a collision practically impossible within the short timeframe thatprevrandaois known.The text was updated successfully, but these errors were encountered: