-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reproduce the attack in paper #199
Comments
The following can't be reproduced (no vuln is found) either with or without flashloan oracle for a 2 hour fuzzing compaign: APC, BGLD, DFS, Discover, DPC, Gym2, HPAY, Nmbplatform, OmniEstate, PancakeHunny, RL, SDAO, TIFI |
Thanks for reporting. I'll keep track of each here.
|
Known working list for BSC exploits: https://github.com/fuzzland/ityfuzz/blob/master/backtesting.md |
Annex seems a false positive:
How does this trace complete the attack? It even doesn't contain the specific liquidator address, who actually lose the fund. |
Same with BEGO, note this attack even doesn't require any flashloan:
The only vulnerable function is Trying to turn of flashloan oracle doesn't help too (not producing any traces). |
ATK seems another fp:
|
Reproduced, looks like just reserves changed. btw, BEGO could be reproduced correctly now. |
I can no longer reproduce Gym_1 after syncing with master branch. Even my previous branch looks like false positive:
Because the root vulnerability |
SImilarly, GDS no longer reproduces after 12 hours fuzzing. |
PancakeHunny seems false positive:
No idea why the address is there. |
RFB seems false positive
According to the analysis here: https://twitter.com/BlockSecTeam/status/1599991294947778560 , the root cause is
I can't see how this triggers |
EGD finance seems the input is improper because the attacker's contract
This gives:
This obviously works because this is the original attacking transaction: https://bscscan.com/tx/0x50da0b1b6e34bce59769157df769eb45fa11efc7d0e292900d6b0a86ae66a2b3 . Note Removing the address from the set and re-running gives another trace:
This looks a bit more promising (reserves changes) so not a big issue. |
Sorry, we merged a PR that breaks the power scheduler, increasing the false negatives. It should be fixed now. I am working on the FP; thanks for reporting! |
I don't see too many improvements regarding reproducing while it crashes more frequently.
|
Can you please share the commands? Thanks |
for SEAMAN ❯ ityfuzz evm -o -t 0x55d398326f99059fF775485246999027B3197955,0x6bc9b4976ba6f8C9574326375204eE469993D038,0x6637914482670f91F43025802b6755F27050b0a6,0xDB95FBc5532eEb43DeEd56c8dc050c930e31017e -c bsc --onchain-block-number 23467515 -f -i -p --onchain-etherscan-api-key XXXX
thread 'main' panicked at src/evm/mod.rs:600:13:
Please specify --deployment-script (The contract that deploys the project) or --offchain-config-file (JSON for deploying the project)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace |
I'm reproducing the result of ityfuzz. I got the sheet from here: #153. However, for the first one AES, ityfuzz fails to give a result in 30 minutes (and seems to be stuck forever). My CLI is:
Enabling flashloan oracle (
-f
) gives a sequence quickly but looks far from an exploit.Even though
reserve
changes and thus the price got manipulated somehow, it's not complete because anyone theoretically can borrow a bunch of tokens and change the price dramatically. That said, I see two problem here:Or does ityfuzz deems this as an exploit?
The text was updated successfully, but these errors were encountered: