Limit Order Bug Bounty

Development & Technical Discussion
#1

What to investigate

All contracts in our /contracts in the repo https://github.com/sushiswap/sushiswap-settlement are eligible for the bounty.

Bounty Size

The size of the bounty will vary depending on the severity of the issue discovered. The severity is calculated according to the OWASP risk rating model based on Impact and Likelihood.

  • Critical: up to 10000 SUSHI
  • High: up to 5000 SUSHI
  • Medium: up to 500 SUSHI
  • Low: up to 100 SUSHI

Submission

If you found a vulnerability, leave a reply with this form:

  • Summary
  • Reproduce Steps
  • URL of source code and line number (optional)
  • Token Names (optional)

If we cannot reproduce an issue we will not be able to reward it.

Other considerations

In addition to severity, other variables are also considered:

  • Quality of description. Higher rewards are paid for clear, well-written submissions.
  • Quality of reproducibility. Please include test code, scripts and detailed instructions. The easier it is for us to reproduce and verify the vulnerability, the higher the reward.
  • Quality of fix, if included. Higher rewards are paid for submissions with clear description of how to fix the issue.
2 Likes
#2

Critical issue:
Cancelled orders are deleted from the testnet. However, a relayer could simply cache the orders and still execute them, even after they are cancelled. This leads to unexpected orders executing and maybe a users makes and cancels 5 orders and later finds all 5 executed, leading to unwanted trades.

Fix: provide on-chain mapping of cancelled hashes. Already discussed with LevX.

Minor issue:


Potential future reentrancy issue: The amount of the order that was filled doesn’t get updated until after external calls. When a user would place a limit buy order for a malicious token contract, this contract could keep executing the order multiple times until the user runs out of funds. So if the user has $10M USDT and puts in a limit order of $5k for a malicious token and the UI did an unlimited approve (pretty standard), the token contract could mint tokens, flashloan USDT, swap up to $10M worth, repay the loan and walk away with $10M in funds.

However, this doesn’t work, because the swap function of SushiSwap has reentrancy protection. But if pointed at a different factory contract or after future updates, this could become an issue, so for safety this should probably be corrected.

Fix: Move the statement up, before the external calls. Already discussed with LevX.

#3

First issue has been fixed: https://github.com/sushiswap/sushiswap-settlement/commit/b95c1f873f7ed9d76757757d486e8b4b88e2e19f

Second one isn’t an issue.

#4

Vulnerability Report- Sensitive Information Disclosure

Hi Team,

I have found one vulnerability of much higher severity. It is as follows:

Weakness: Sensitive Information Disclosure

Severity: High-Critical (P1) - CWE-200

Target : Sushiswap github rep

Summary:

After some research, I found a leak on GitHub that leads to accessing sensitive data of private API keys,private keys and other sensitive information.GitHub is a truly awesome service but it is unwise to put any sensitive data in code that is hosted on GitHub and similar services.Such keys are vulnerable and has been misused before by the attackers.

POC:

Sensitive Information Leakage:

Infura API Key:

Here you can see that the Infura API keys is visible which should have been hidden in the .gitignored file. Such infura API keys are vulnerable to rate limit attacks.

Other Api Keys Including Firebase

https://github.com/sushiswap/sushiswap-lite/blob/aeb0d7e47978e4100f4c2a87c85b773732dde04d/app.json

Impact:

High potential of an unauthorized access to PII data and misuage/attack.

Looking forward to hear from you soon on this.

Regards,
Phoenix

1 Like
#5

That infura key isn’t being used anymore. Also, it’s completely okay that the firebase config file is leaked.

1 Like
#6

Actually no.

This key is unrestricted. To prevent unauthorized use and quota theft, restrict your key. Key restriction lets you specify which websites, IP addresses, or apps can use this key.

There you can choose HTTP referrers (websites) and add your domain. This means that the Firebase database will only accept requests for people writing from that domain.

Or Android apps and iOS apps, where you can add package name and fingerprints.

For example:

If you build myawesomeapp.com and add the domain in the HTTP referrers (websites) section, any attacker trying to connect from a different domain will get an error, and those requests will never make it to the database.

#7

Just found your infura key:

1 Like
#8

any update on my latest submits?