Skip to content

Latest commit

 

History

History
54 lines (37 loc) · 2.63 KB

098.md

File metadata and controls

54 lines (37 loc) · 2.63 KB
Raw

Sparkly Seaweed Wolf

Medium

Possible re-org attack for registerAddress

Summary

Base chain user the similar structure with Op chain. This will cause the possible re-org case. When we register address, we miss enough check to avoid the possible reorg attack.

Root Cause

In EthosProfile:373, users can register one address into their profiles. They will get one signature from Ethos app, and register this address into their profile. But the problem is that if re-org happens, the registered address may be registered to other user's profile and this register address may not be used any more.

From readme, we can find that the Ethos app will be deployed on Base L2 chain. Base Chain has one similar structure with Op chain. Both of them may have the possible re-org case. For example:

  1. Alice creates one profile, and the profile is 2.
  2. Alice register her another address X into the profile 2.
  3. If re-org happens, Bob monitors the re-org case, can create one profile before Alice's profile creation, then the profileId 2 will belongs to Alice.
  4. Alice's profile creation will be re-executed but the generated profileId will be 3.
  5. Alice register her address X into profile 2. Note, the signature is valid here.
  6. Alice's address X will be registered to Bob's profile. Bob can directly remove address X. Then Alice's address X will never be used again.

Internal pre-conditions

N/A

External pre-conditions

  1. Re-org happens in Base chain.
  2. Bob creates one profile before Alice's creation.

Attack Path

  1. Alice creates one profile, and the profile is 2.
  2. Alice register her another address X into the profile 2.
  3. If re-org happens, Bob monitors the re-org case, can create one profile before Alice's profile creation, then the profileId 2 will belongs to Alice.
  4. Alice's profile creation will be re-executed but the generated profileId will be 3.
  5. Alice register her address X into profile 2. Note, the signature is valid here.
  6. Alice's address X will be registered to Bob's profile. Bob can directly remove address X. Then Alice's address X will never be used again.

Impact

Users may not register his address into his profile as expected. And this address will never be used in this system.

PoC

N/A

Mitigation

Possible solution:

  1. Only addressStr can register himself into one profile.
  2. When we create profile, change profileId to byte32 type, and add some salt information into profileId, for example creator. So even if re-org happens, other profile creators cannot own the same profileId.