Tigris Trade contest - orion's results

A multi-chain decentralized leveraged exchange featuring instant settlement and guaranteed price execution on 30+ pairs.

General Information

Platform: Code4rena

Start Date: 09/12/2022

Pot Size: $90,500 USDC

Total HM: 35

Participants: 84

Period: 7 days

Judge: GalloDaSballo

Total Solo HM: 12

Id: 192

League: ETH

Tigris Trade

Findings Distribution

Researcher Performance

Rank: 64/84

Findings: 2

Award: $32.20

🌟 Selected for report: 0

πŸš€ Solo Findings: 0

Findings Information

🌟 Selected for report: KingNFT

Also found by: 0x52, Critical, chaduke, noot, orion

Labels

bug
2 (Med Risk)
downgraded by judge
partial-25
edited-by-warden
duplicate-108

Awards

31.0541 USDC - $31.05

External Links

Lines of code

https://github.com/code-423n4/2022-12-tigris/blob/b2ebb8ea1def4927a747e7a185174892506540ab/contracts/utils/TradingLibrary.sol#L91-L104

Vulnerability details

Impact

The verifyPrice function verifiers whether the given price data (PriceData calldata _priceData,) of an asset is correct based on the signature given by the provider ( bytes calldata _signature), if so it will process the transaction based on logic, the signature is protected by the block.timestamp and the data time, however this doesn't make it fully protected, a signature replay attack can still occurs, a malicious actor can resend an old pricedata with it's used signature and it will make the price as valid while it's not

we can see that it verifies the price lately with the chainlink price (price < assetChainlinkPrice+assetChainlinkPrice2/100 && price > assetChainlinkPrice-assetChainlinkPrice2/100) however it still exploitable when we set _chainlinkEnabled to false and it will avoid the whole the verification from ChainLink

Proof of concept :

(Remix IDE)

//SPDX-License-Identifier: MIT pragma solidity ^0.8.0; import "https://github.com/code-423n4/2022-12-tigris/blob/b2ebb8ea1def4927a747e7a185174892506540ab/contracts/utils/TradingLibrary.sol#L104"; contract example { mapping(address=>bool) public _isNode; constructor() public { _isNode[msg.sender] = true; } function test(uint256 _validSignatureTimer, uint256 _asset, bool _chainlinkEnabled, address _chainlinkFeed, PriceData calldata _priceData, bytes calldata _signature) { TradingLibrary.verifyPrice(_validSignatureTimer,_asset,_chainlinkEnabled,_chainlinkFeed,_priceData,_signature,_isNode); // do the next stuff } }

With your wallet (as node) sign the hash with the valid priceData tuple (make the _validSignatureTimer high), and call the test function (set _chainlinkEnabled to false to avoid), transaction will succeed, supposing the price updated ...etc we re-call the function with the same data previously and the call will succeed

Tools Used :

Manual

Use nonce and verified in the PriceData, and within the verifyPrice function update it further

#0 - GalloDaSballo

2022-12-22T02:51:57Z

Missing further detail but ultimately is dup of more developed reports, will award 25%

#1 - c4-judge

2022-12-22T02:52:12Z

GalloDaSballo marked the issue as duplicate of #108

#2 - c4-judge

2022-12-22T02:52:21Z

GalloDaSballo marked the issue as partial-25

#3 - c4-judge

2023-01-16T09:45:17Z

GalloDaSballo changed the severity to 2 (Med Risk)

Awards

1.1472 USDC - $1.15

Labels

bug
2 (Med Risk)
disagree with severity
downgraded by judge
satisfactory
sponsor confirmed
edited-by-warden
duplicate-377

External Links

Lines of code

https://github.com/code-423n4/2022-12-tigris/blob/b2ebb8ea1def4927a747e7a185174892506540ab/contracts/utils/TradingLibrary.sol#L95

Vulnerability details

Impact

The TradingLibrary> verifyPrice function verifies the given price with the node signature, however it reverts if the signed price is different than the chainLink price feed if the price slipped during "_priceData.timestamp + _validSignatureTimer", however this design can be bypassed as the priceFeed address is given by the user (address _chainlinkFeed) doing so an attacker can deploy a fake price feed and give it in the arg and give it's controlled price, this will make the attacker benefits from slippage ...etc

Proof of Concept

(Remix IDE), supposing the price is 400 however the price from the chainlink price feed is 900 (this will make 400 > 900-900*2/100 reverts)

//SPDX-License-Identifier: MIT pragma solidity ^0.8.0; import "https://github.com/code-423n4/2022-12-tigris/blob/b2ebb8ea1def4927a747e7a185174892506540ab/contracts/utils/TradingLibrary.sol#L104"; contract fake { function decimals() external view returns(uint256) { return 18; } function latestAnswer() external view returns (int256) { return 400; } } contract example { mapping(address=>bool) public _isNode; constructor() public { _isNode[msg.sender] = true; } function test(uint256 _validSignatureTimer, uint256 _asset, address _chainlinkFeed, PriceData calldata _priceData, bytes calldata _signature) { TradingLibrary.verifyPrice(_validSignatureTimer,_asset,true,_chainlinkFeed,_priceData,_signature,_isNode); // do the next stuff } }

With your wallet (as node) sign the hash with the valid priceData tuple (make the _validSignatureTimer high and the price is 400), supposing the current price of the asset is 900 but the signature is made for 400 as price, call the test function with the fake contract as _chainlinkFeed and the transaction will succeed

Tools Used

Manual

Make a whitelisting to the _chainlinkFeed :

mapping(address=>bool) whitelisted; ... require(whitelisted[_chainlinkFeed],"unknown chainlink feed");

#0 - GalloDaSballo

2022-12-22T02:55:08Z

Warden's submission is effectively saying you can use an arbitrary feed.

In reality the signer will not allow that: https://github.com/code-423n4/2022-12-tigris/blob/b2ebb8ea1def4927a747e7a185174892506540ab/contracts/utils/TradingLibrary.sol#L105

However, this still falls as a risk from Centralization as the signer can use any new feed at will

#1 - TriHaz

2022-12-23T03:59:46Z

It is valid, there should be a whitelist mapping for chainlink feeds, but I disagree with severity as an attacker would need to manipulate the price on our oracle too to take advantage of this issue, as @GalloDaSballo mentioned, signer is checked.

#2 - c4-sponsor

2022-12-23T03:59:51Z

TriHaz marked the issue as sponsor confirmed

#3 - c4-sponsor

2022-12-23T03:59:56Z

TriHaz marked the issue as disagree with severity

#4 - c4-judge

2022-12-23T17:50:43Z

GalloDaSballo marked the issue as duplicate of #418

#5 - c4-judge

2023-01-15T13:54:57Z

GalloDaSballo marked the issue as duplicate of #377

#6 - c4-judge

2023-01-15T13:56:11Z

GalloDaSballo changed the severity to 2 (Med Risk)

#7 - c4-judge

2023-01-23T09:04:21Z

GalloDaSballo marked the issue as satisfactory

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax Β© 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter