Skip to content
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

Medusa crash when deploying contract inside target contract constructor #211

Closed
aviggiano opened this issue Aug 23, 2023 · 5 comments · Fixed by #216
Closed

Medusa crash when deploying contract inside target contract constructor #211

aviggiano opened this issue Aug 23, 2023 · 5 comments · Fixed by #216

Comments

@aviggiano
Copy link

aviggiano commented Aug 23, 2023

Hello,

Medusa is crashing with the following error

[I] ➜ medusa fuzz
⇾ Reading the configuration file at: .../medusa.json
⇾ Compiling targets with crytic-compile
⇾ fuzz: elapsed: 0s, calls: 0 (0/sec), seq/s: 0, coverage: 0
⇾ Creating 10 workers...
panic:

goroutine 69 [running]:
github.com/rs/zerolog.(*Logger).Panic.func1({0x0?, 0x0?})
	.../go/pkg/mod/github.com/rs/zerolog@v1.29.0/log.go:376 +0x30
github.com/rs/zerolog.(*Logger).newEvent(0x14000193088, 0x5, 0x104faa030)
	.../go/pkg/mod/github.com/rs/zerolog@v1.29.0/log.go:449 +0x4c
github.com/rs/zerolog.(*Logger).Panic(0x1400083c418?)
	.../go/pkg/mod/github.com/rs/zerolog@v1.29.0/log.go:376 +0x28
github.com/crytic/medusa/logging.(*Logger).Panic(0x14000193080, {0x1400083c418?, 0x5c0a130bd5b1043c?, 0x126533220e92e5df?})
	.../Documents/medusa/logging/logger.go:287 +0x68
github.com/crytic/medusa/fuzzing/coverage.(*CoverageTracer).CaptureState(0x0?, 0x0?, 0x0?, 0x0?, 0x0?, 0x140040012d8, {0x0?, 0x0?, 0x0?}, 0x0?, ...)
	.../Documents/medusa/fuzzing/coverage/coverage_tracer.go:160 +0x1f0
github.com/crytic/medusa/chain.(*TestChainTracerRouter).CaptureState(0x1400159dc20?, 0x140008a9980?, 0xd8?, 0x104522b8c?, 0x1400083c568?, 0x104b55b80?, {0x0, 0x0, 0x0}, 0x4?, ...)
	.../Documents/medusa/chain/test_chain_tracer.go:106 +0xd0
github.com/ethereum/go-ethereum/core/vm.(*EVMInterpreter).Run(0x140008a9980, 0x140038ff440, {0x140001d9460, 0x42, 0x220}, 0x0)
	.../go/pkg/mod/github.com/crytic/medusa-geth@v0.0.0-20230811005223-cee04520a2f9/core/vm/interpreter.go:225 +0x6c0
github.com/ethereum/go-ethereum/core/vm.(*EVM).Call(0x1400159dc20, {0x104faf780, 0x140038ff140}, {0x82, 0xd8, 0x74, 0xe5, 0x9f, 0x27, 0x4c, ...}, ...)
	.../go/pkg/mod/github.com/crytic/medusa-geth@v0.0.0-20230811005223-cee04520a2f9/core/vm/evm.go:239 +0x920
github.com/ethereum/go-ethereum/core/vm.opCall(0x1400159dc20?, 0x140008a9980, 0x14004001170)
	.../go/pkg/mod/github.com/crytic/medusa-geth@v0.0.0-20230811005223-cee04520a2f9/core/vm/instructions.go:686 +0x4f4
github.com/ethereum/go-ethereum/core/vm.(*EVMInterpreter).Run(0x140008a9980, 0x140038ff140, {0x1400089ca20, 0x104, 0x120}, 0x0)
	.../go/pkg/mod/github.com/crytic/medusa-geth@v0.0.0-20230811005223-cee04520a2f9/core/vm/interpreter.go:229 +0x700
github.com/ethereum/go-ethereum/core/vm.(*EVM).Call(0x1400159dc20, {0x104fb0c00, 0x140038c0960}, {0x54, 0x91, 0x9a, 0x19, 0x52, 0x2c, 0xe7, ...}, ...)
	.../go/pkg/mod/github.com/crytic/medusa-geth@v0.0.0-20230811005223-cee04520a2f9/core/vm/evm.go:239 +0x920
github.com/ethereum/go-ethereum/core.(*StateTransition).TransitionDb(0x1400083d4c0)
	.../go/pkg/mod/github.com/crytic/medusa-geth@v0.0.0-20230811005223-cee04520a2f9/core/state_transition.go:376 +0x7a4
github.com/ethereum/go-ethereum/core.ApplyMessage(0x1400083d568?, 0x10474b59c?, 0x104fa0d00?)
	.../go/pkg/mod/github.com/crytic/medusa-geth@v0.0.0-20230811005223-cee04520a2f9/core/state_transition.go:176 +0x4c
github.com/crytic/medusa/chain/vendored.EVMApplyTransaction(0x140008db290, 0x140008a0000, 0x7735940?, 0x1400403c480?, 0x140038bf6c0, 0x1400403c320, {0x3e, 0x4, 0x68, 0x98, ...}, ...)
	.../Documents/medusa/chain/vendored/apply_transaction.go:44 +0x248
github.com/crytic/medusa/chain.(*TestChain).PendingBlockAddTx(0x140038c2640, 0x140008db290)
	.../Documents/medusa/chain/test_chain.go:712 +0x454
github.com/crytic/medusa/fuzzing/calls.ExecuteCallSequenceIteratively(0x140038c2640, 0x1400083dd58, 0x1400083ddb0)
	.../Documents/medusa/fuzzing/calls/call_sequence_execution.go:87 +0x39c
github.com/crytic/medusa/fuzzing.(*FuzzerWorker).testNextCallSequence(0x14000892000)
	.../Documents/medusa/fuzzing/fuzzer_worker.go:299 +0xf4
github.com/crytic/medusa/fuzzing.(*FuzzerWorker).run(0x14000892000, 0x7?)
	.../Documents/medusa/fuzzing/fuzzer_worker.go:565 +0x27c
github.com/crytic/medusa/fuzzing.(*Fuzzer).spawnWorkersLoop.func1({0x0?, 0x1400075f1a0?})
	.../Documents/medusa/fuzzing/fuzzer.go:534 +0x194
created by github.com/crytic/medusa/fuzzing.(*Fuzzer).spawnWorkersLoop
	.../Documents/medusa/fuzzing/fuzzer.go:517 +0x284

You can find below a repo with a MWE

https://github.com/aviggiano/medusa-crash

@anishnaik
Copy link
Collaborator

anishnaik commented Sep 1, 2023

@aviggiano feel free to check out https://github.com/crytic/medusa/tree/dev/fix-coverage-panic

This should have the fix in place. Here is what the issue was:

Basically, if you recall from our conversation about medusa, medusa will call any function in any dynamically deployed contract. Thus, medusa was calling Deployer.deploy with arbitrary bytecode as an input argument. When we were tracking coverage for that bytecode, we assumed that the program counter in the EVM could never be greater than the length of the bytecode. However, this is not true for arbitrary bytecode because I can craft bytecode that will cause the program counter to be greater than the length of the bytecode which caused a panic in medusa. Example: if the length of my bytecode is 2 but the first byte is PUSH11 then the program counter will become 12 but the length still remains as 2.

Please let me know if this works for you.

@anishnaik
Copy link
Collaborator

You can also use this branch: https://github.com/crytic/medusa/tree/dev/merge-assertion-and-property-mode

That has both support for payable constructors and fixes the panic.

@aviggiano
Copy link
Author

aviggiano commented Sep 1, 2023

Hey @anishnaik

Thank you for the quick update.
I'm still running into issues on the original repo, so I have updated the MWE to actually perform a create3 deployment, which leads to the execution stopping:

[I] ➜ medusa fuzz
⇾ Reading the configuration file at: medusa.json
⇾ Compiling targets with crytic-compile
⇾ Creating 10 workers...
⇾ fuzz: elapsed: 0s, calls: 0 (0/sec), seq/s: 0, coverage: 0
error Encountered an error in the main fuzzing loop
‣ could not match bytecode of a deployed contract to any contract definition known to the fuzzer
⇾ Fuzzer stopped, test results follow below ...
⇾ [PASSED] Assertion Test: EchidnaTester.test1p1eq2()
⇾ Test summary: 1 test(s) passed, 0 test(s) failed

Echidna by contrast does not stop the execution

echidna Echidna.sol --contract EchidnaTester  --crytic-args "--solc-remaps  @crytic/properties/=lib/properties/" --test-mode assertion

[2023-09-01 16:46:50.13] Compiling Echidna.sol... Done! (0.423294s)
Analyzing contract: Echidna.sol:EchidnaTester
[2023-09-01 16:46:50.59] Running slither on Echidna.sol... Done! (0.747945s)
test1p1eq2(): passing
AssertionFailed(..): passing

@anishnaik
Copy link
Collaborator

anishnaik commented Sep 1, 2023

@aviggiano can you try toggling fuzzing.testing.stopOnFailedContractMatching to false? What is happening is that the deployment of the authority contract does not have an ABI that we can match it to - which is what the error is saying. Turning that off will allow you to continue fuzzing.

@aviggiano
Copy link
Author

Hey @anishnaik

Thank you very much, this solves my problem!

I'm looking forward to trying medusa out, I'll keep you posted.

Best

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants