-
Notifications
You must be signed in to change notification settings - Fork 50
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
Broken Dataflow #87
Comments
The dataflow analysis is correct. The reason this does not get detected is that by default Securify would decompile methods and compute a local, per-method dataflow fixpoint. Disabling method decompilation results in computing a global dataflow fixpoint that passes this test. |
So shall I just remove the Decompiler and use the DecompilerFallback as default? |
Can you rerun the test cases with this change so that we can evaluate the difference? |
Rerunning now, one thing though is that the MissingInputValidation pattern depends on the method decompilation. We could also just have the method decompilation for this pattern and the fallback decompilation for the others. |
Difference available on |
Thanks. Do we have an ordered diff somewhere, so it is easier to see what changed? |
Try with 2b72e5f and let me know if that works for you. |
When I rebase to the specified commit the issue is gone.
The relevant code is: https://github.com/eth-sri/securify/blob/broken_dataflow/src/test/resources/solidity/LockedEther.sol The returned result is |
The
mayFollow
relation does not correctly capture dataflow dependencies.Example:
It does not identify that function
x()
may follow itself.A test case is provided inside the
broken_dataflow
branch (https://github.com/eth-sri/securify/tree/broken_dataflow).Simply run
./gradlew test
to trigger.The text was updated successfully, but these errors were encountered: