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

Broken Dataflow #87

Open
ritzdorf opened this issue Feb 8, 2019 · 8 comments
Open

Broken Dataflow #87

ritzdorf opened this issue Feb 8, 2019 · 8 comments
Labels
Bug Something isn't working

Comments

@ritzdorf
Copy link
Collaborator

ritzdorf commented Feb 8, 2019

The mayFollow relation does not correctly capture dataflow dependencies.

Example:

contract A {
  	address a;
	function f() public view returns(address) {
    	    return a;
        }
}

contract B {
    mapping(address => bool) approved;
    mapping(address => bool) modified;

    function x(A a) internal returns(address){
        return address(a.f());
    }

    function g(A a) public {
        require(approved[x(a)]);
        modified[x(a)] = true;
     }
}

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.

@ritzdorf ritzdorf added the Bug Something isn't working label Feb 8, 2019
@ptsankov
Copy link
Collaborator

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.

@hiqua
Copy link
Contributor

hiqua commented Feb 18, 2019

So shall I just remove the Decompiler and use the DecompilerFallback as default?

@ritzdorf
Copy link
Collaborator Author

Can you rerun the test cases with this change so that we can evaluate the difference?

@hiqua
Copy link
Contributor

hiqua commented Feb 19, 2019

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.

@hiqua
Copy link
Contributor

hiqua commented Feb 19, 2019

Difference available on comparison_decompiler_fallback.

@ritzdorf
Copy link
Collaborator Author

Thanks. Do we have an ordered diff somewhere, so it is easier to see what changed?

@hiqua
Copy link
Contributor

hiqua commented Feb 20, 2019

Try with 2b72e5f and let me know if that works for you.

@ritzdorf
Copy link
Collaborator Author

ritzdorf commented Mar 5, 2019

When I rebase to the specified commit the issue is gone. ./gradlew test gets two new errors:

  1. Is about MissingInputValidation. That is expected and we are fixing it elsewhere.
  2. Is about this check
    assertEquals(2, instructionPatternTest.pattern.violations.size());

The relevant code is: https://github.com/eth-sri/securify/blob/broken_dataflow/src/test/resources/solidity/LockedEther.sol

The returned result is 1 but the expected result is 2, but I find that 1 is the correct result, so overall it seems to fix things.

@hiqua hiqua removed their assignment Mar 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants