Open hats-bug-reporter[bot] opened 1 month ago
the user can pass in a malicious market address to redeem position and cause loss of fund.
That's safety, not security. That can be fixed at the UI level to prevent users from being exposed to malicious markets. Also:
Out of Scope:
Issues about being able to create malicious markets (for example, you can create markets without using the MarketFactory with a malicious arbitrator, create child markets to it) as long as this wouldn't result in those being displayed in the interface looking like a normal markets (if a child market of a malicious market is displayed, but points to some market which is not displayed, cannot be interacted with or is labelled as problematic, we consider it fine as it would not get verified on Curate).
For example in Split position
@greenlucid
// wrap & transfer the minted outcome tokens.
for (uint256 j = 0; j < partition.length; j++) {
uint256 tokenId = getTokenId(collateralToken, parentCollectionId, conditionId, partition[j]);
(IERC20 wrapped1155, bytes memory data) = market.wrappedOutcome(j);
// wrap to erc20.
conditionalTokens.safeTransferFrom(address(this), address(wrapped1155Factory), tokenId, amount, data);
// transfer the ERC20 back to the user.
wrapped1155.transfer(msg.sender, amount);
}
this is the code in split Position,
the problem is that in this case,
it is clear that
It is expect that user should wrap conditional token A to get wrapped1155 A.
But the user can wrap conditional token A and get wrapped1155 B
because user control the returned wrapped1155 and return data.
(IERC20 wrapped1155, bytes memory data) = market.wrappedOutcome(j);
then user can unwrap wrapped1155 B and redeem the position from token B, it is not about create malicious market to display on UI, it is about mint wrapped1155 B maliciously and redeem them later.
The router is just there to do a lot of stuff at once instead of asking the user to sign a ton of TX. As pointed out by Green, it's possible to create malicious markets (by creating those contracts directly), but those won't be picked up by the frontend.
As per contest rules, are excluded:
If you think your issue is correct, please explain how someone could call the router to harm others.
Github username: -- Twitter username: -- Submission hash (on-chain): 0x16d2d7fca2419473c409d739985e1d0e9a0f002935a7cce1e18380c4abaee0f8 Severity: high
Description: Description\ Describe the context and the effect of the vulnerability.
Attack Scenario\
https://github.com/hats-finance/SeeR-PM-0x899bc13919880db76edf4ccd72bdfa5dfa666fb7/blob/4e56254cbd071b6f678a108ccdb8660951636d27/contracts/src/Router.sol#L143
the input market is not validated.
the user can pass in a malicious market address to redeem position and cause loss of fund.
https://github.com/hats-finance/SeeR-PM-0x899bc13919880db76edf4ccd72bdfa5dfa666fb7/blob/4e56254cbd071b6f678a108ccdb8660951636d27/contracts/src/Router.sol#L167
all external query to market contract is labeled with @
a malicious market contract can be
for example, the user can make a market with no parentCollectionId return a parentCollectionId that comes from another market, etc..
basically the parameter market needs to be validated in every function in router contract (split, merge, and redeem)
the fix is in the MarketFactory as well.
and then in the router contract, check if the market contract comes from the market factory
Attachments
Proof of Concept (PoC) File
Revised Code File (Optional)