The soulmate::mintSoulmateToken
public function allows anybody to assign themselves as their own soulmate, which completely undermines the intended functionality of the contract. This essentially enables anyone to "get divorced" from themselves.
Alice, an Ethereum account holder with the address 0xef211076B8d8b46797E09c9a374Fb4Cdc1dF0916
, initiates the minting process for a soulmate token using the soulmate::mintSoulmateToken
public function. At the time of initiation, Alice does not have an assigned soulmate. Consequently, the initial require check passes, and Alice is assigned tokenId
or nextID
0
, indicating the first soulmate slot.
Recognizing a vulnerability within the contract, Alice attempts to designate herself as her own soulmate by invoking the minting function again with her EOA (Externally Owned Account) Ethereum account address 0xef211076B8d8b46797E09c9a374Fb4Cdc1dF0916
. Since Alice does not have an assigned soulmate yet, the initial require check is satisfied once more. However, the subsequent logic check fails due to her ownership of tokenId
0
. As a result, the else if
condition succeeds as soulmate2
, corresponding to nextID
, remains unclaimed.
By exploiting this vulnerability, Alice inadvertently assigns herself as her own soulmate. As she already owns slot 1
with nextID
0
, the logic flow allows her to claim ownership of slot 2
at index 1
using the statements idToOwners[nextID][1] = msg.sender
and ownerToId[msg.sender] = nextID
.
Consequently, Alice is effectively reunited with herself within the contract, as evidenced by the assignment statements soulmateOf[msg.sender] = soulmate1
and soulmateOf[soulmate1] = msg.sender
.
Furthermore, the soulmate::mintSoulmateToken
function emits an event named SoulmateAreReunited
upon execution, with both soulmate1
and soulmate2
referencing Alice's Ethereum account address 0xef211076B8d8b46797E09c9a374Fb4Cdc1dF0916
, and nextID
indicating 0
.
Take a look at this Poc Foundry Test
...
Place the following test code snippet into the test/unit/soulmateTest.t.sol
file. Put it at the very bottom but before the last closing semicolon }
.
Open Your Bash Terminal
and execute the following command...
Some output might appear upon executing the above command. Take a look at that output.
People can mint, earn, and stake loveTokens
by assigning themselves as their own soulmates
. They can even initiate a "divorce" from themselves. This capability allows anyone to disrupt Valentine's day and compromise the integrity of the entire Soulmate Contract | Protocol.
Foundry Framework (Solidity, Rust)
The easiest mitigation could be:
Implement an if
check to verify that the second person isn't the first person attempting to make themselves their soulmate.
Make the following changes in src/Soulmate.sol
:
After implementing & Updating Soulmate.sol
with the above mitigation code. Place the following test code snippet into the test/unit/soulmateTest.t.sol file. Put it at the very bottom but before the last closing semicolon }
.
Open Your Bash Terminal
and execute the following command...
Ouput should indicate that test Passed Successfully.
- Given the native anonymous nature of blockchain in general, this issue cannot be avoided unless an explicit whitelist is implemented. Even then we can only confirm soulmates are distinct individuals via kyc. I believe finding a soulmate is intended to be permisionless. - However, even though sufficient (500_000_000e18 in each vault) tokens are minted to claim staking and airdrop rewards, it would take 500_000_000 / 2 combined weeks for airdrop vault to be drained which is not unreasonable given there are [80+ million existing wallets](https://coinweb.com/trends/how-many-crypto-wallets-are-there/). Given there is no option to mint new love tokens, this would actually ruin the functionality of the protocol of finding soulmates and shift the focus to abusing a sybil attack to farming airdrops instead. Assigning medium severity for now but am open for appeals otherwise, since most if not all issues lack indepth analysis of the issue.
- Given the native anonymous nature of blockchain in general, this issue cannot be avoided unless an explicit whitelist is implemented. Even then we can only confirm soulmates are distinct individuals via kyc. I believe finding a soulmate is intended to be permisionless. - However, even though sufficient (500_000_000e18 in each vault) tokens are minted to claim staking and airdrop rewards, it would take 500_000_000 / 2 combined weeks for airdrop vault to be drained which is not unreasonable given there are [80+ million existing wallets](https://coinweb.com/trends/how-many-crypto-wallets-are-there/). Given there is no option to mint new love tokens, this would actually ruin the functionality of the protocol of finding soulmates and shift the focus to abusing a sybil attack to farming airdrops instead. Assigning medium severity for now but am open for appeals otherwise, since most if not all issues lack indepth analysis of the issue.
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.