DFG Fixes: Inconsistencies, Problems, Discussionworthy

[konradweiss]

Specific data flows of the code below are extracted to show how the DFG is build and where problems can be identfied.

Calls

public class Calls {

    public static void main(String[] args) {
        System.out.println(resolvableCall(1));
        System.out.println(unresolvableCall(2));

        Calls call = new Calls();

        System.out.println(call.resolvableMemberCall(3));
        System.out.println(call.unresolvableMemberCall(4));

    }
    private int resolvableMemberCall(int param){
        return param + 2;
    }
    private static int resolvableCall(int param){
        return param+1;
    }
}

Info

Data flows from args to parameters over expressions are propagated to the return statement and over the FunctionDeclaration-Node back to the call.

The implicit Constructor is connected to the ConstructExpression

The implicit return is also connected to the main

Problem

IMO there should definitely be a DFG Edge between the NewExpression and the contained ConstructExpression

Discussion

For a security Analysis we may want to be on the save side and connect args to the call with a dfg edge if we could not resolve the function target.

ConditionalOperator

int main() {
  int a = 0;
  int b = 1;

  a = a == b ? b = 2: b = 3;
  a = b;
}

Info

Data used in a condition flows to the root node of the enclosing statement to use its result and know the semantic of what it is used for (the root node represents the context of use).

Data in expressions that use = flows over the operator =

Discussion

Here I see something that could be perceived as inconsistency: The DFs on the left, toward to root node go over the =-operator as there it is and expression, while the DFs to the VariableDeclaration do not go over the = operator. Here we could let the values always flow over the =-Operator, and ignore the LHS-Reference. This would also solve a Problem that we see later with the self-operators. However, this is not something that arises from algorithm problem

ControlFlowSensitivity

class ControlFlowSensitive {
    public static void main(String[] args) {
        int a = 0;
        if(a % 2 == 0){
            a = 1;
        }else{
            a = 2;
            System.out.println(a);
        }
        System.out.println(a);
    }
}

Info

Here again we see the condition being evaluated and flowing to the root node of the IfStatement

The ControlFlowSensitivity can be seen on the right side where the upper a is used in the print outside of the if and has to consider all values written in the branches, and the lower a that only has to consider the most recent write in its own branch.

Returns

class Returns {
    public static void main(String[] args) {
        System.out.println(functionThatReturns(1));
    }

    public static int functionThatReturns(int a){
        if(a % 2 == 0){
            return a + 1;
        }else{
            return a;
        }
    }
}

Problem

I identified an issue that apparently only arises when we have multiple returns in a function, only one return has a DFG-Edge to the Function root, and all should have one

SelfOperators

public class SelfOperators {

    public static void main(String[] args) {
        int a = 0;
        a++;
        System.out.println(a);

        a += 3;
        System.out.println(a);

    }
}

Problem

Due to some changes the reference of the previous value to the references got lost. In this image we are missing a DFG-Edge from the Literal on the left side to the ++ and one from the result of ++ or its reference to the +=. This is an issue that I thought we solved but appears to still be there. This is an additional reason to used the operator = or ++ and += as data flow start to points-of-use and Declarations.

ImplicitReturn

void fun() {
    int a = 2;
}

int main() {
    fun();
    return 0;
}

Discussion

A DF from a function with return type void. Nothing is actually returned but we still have a DF. This DF might be acceptable because (1) void is a type in some languages and (2) it helps in modelling other function calls.

[fwendland]

Decisions:

• DFG from ConstructExpression to NewExpression
• Configuration object for inference engine
  • DFG for unknown functions from parameter into FunctionDeclaration
• this references are postponed (slightly better implementations for Python and Go; may be adapted)
• Check ConditionalOperator : Is there a dataflow from operator == into the conditional operator ?:?
• DFG for conditional operator
  • Add PropertyEdge support for DFG edges
  • Add implicit dataflow from comparison operator into orange node of coditional expression
• Keep only dataflows from operator to variable (i.e. green to violet to red; no shortcuts directly into variable reference)
• Returns : May have 3 return because one for each branch and an implicit after the if-else (which is dead code)?
• Postpone SelfOperator

[KuechA]

How do we model currently the data flows for an "unresolvable call"? How is the base of such a call involved? In your example above, if we use String s = call.unresolvableMemberCall(4);, I believe that there should be a data flow from call (and according to the discussion also from 4) to s. I think that this is not the case yet.

Where and how should this be implemented?