Missed sink after second class instantiation

[draftyfrog]

Please consider the following code:

 MyClass myVar = new MyClass();
 myVar.myString = source();
 MyClass mySecondVar = new MyClass(); // If this statement is removed, the leak in the next statement is reported correctly
 sink(myVar.myString); // NOT reported by FlowDroid

where public String source() and public void sink(String param) are defined as source and sink respectively in the FlowDroid config and the custom class MyClass looks like this:

class MyClass{
  String myString;
}

As annotated, FlowDroid doesn't report the leak, as long as the second instantiation is present. This is probably linked to #767 as for example adding System.out.println(mySecondVar); between the instantiation of mySecondVar ans the sink call also leads to the leak being correctly reported.

I'm using one of the newest version of FlowDroid: Commit a137b4d and the issue seems to be rather new as well: FlowDroid 2.14.1 correctly detects the leak.

SourcesAndSinks.xml

<sinkSources>
    <category id="NO_CATEGORY" description="no_category">
        <method signature="com.example.testapp.MainActivity: java.lang.String source()">
            <return type="java.lang.String">
                <accessPath isSource="true" isSink="false">

                </accessPath>
            </return>
        </method>
        <method signature="com.example.testapp.MainActivity: void sink(java.lang.String)">
            <param index="0" type="java.lang.String">
                <accessPath isSource="false" isSink="true"/>
            </param>
        </method>
    </category>
</sinkSources>

I call FlowDroid via the command line

java -jar ./soot-infoflow-cmd-a137b4d-jar-with-dependencies.jar \
 -a {path-to-apk} \
 -s ./SourcesAndSinks.xml \
 -o ./out.xml \
 -p {path-to-android-platforms-folder} \
 --mergedexfiles 

[StevenArzt]

I have added a test case which works fine. Can you provide your APK file?

[draftyfrog]

Sure, you can find it attached: app-debug.zip

[draftyfrog]

I no longer have the issue using the latest commit (3a45a5d) if I call it from the command line as specified above.
Seems like this is related to aliasing, because if I use the option --aliasalgo NONE (or LAZY), the issue remains, no leaks are reported. Is it similar to the issue 799?
I'm not sure when I should use which options of aliasalgo (since my Java code doesn't contain aliasing here), is there a guideline for this?

[t1mlange]

Exactly, without precise aliasing information, it will miss the (r2, $r4) relationship.

java.lang.String $r3;
com.example.testapp.MyClass r2, $r4;

$r4 = new com.example.testapp.MyClass;
specialinvoke $r4.<com.example.testapp.MyClass: void <init>()>();
r2 = $r4;
$r3 = virtualinvoke r0.<com.example.testapp.MainActivity: java.lang.String source()>();
$r4.<com.example.testapp.MyClass: java.lang.String myString> = $r3;
$r4 = new com.example.testapp.MyClass;
specialinvoke $r4.<com.example.testapp.MyClass: void <init>()>();
$r3 = r2.<com.example.testapp.MyClass: java.lang.String myString>;
virtualinvoke r0.<com.example.testapp.MainActivity: void sink(java.lang.String)>($r3);

Any non-trivial program will have aliases of some sort or another. It seems that the DEX frontend especially likes to create those aliases and, sometimes, optimizations resolve these cases again (I've fixed one of these long time ago by just adding copy propagation in-between).

Regarding aliasalgo, I think I never used FlowDroid with anything except the default on-demand alias algorithm.

I know that Soot sometimes generates suboptimal Jimple and I have published thesis topic about the phase-ordering problem for data-flow analysis but haven't found a student yet.

[StevenArzt]

In general, the source code you write as a developer may structurally differ from the Dalvik bytecode, which in turn may differ from the Jimple code. In the first step, your compiler may perform optimizations or simply generate patterns you didn't expect (e.g., access method when calling private methods in outer classes). You move from variables in your code to registers in Dalvik.

In the second step, Jimple has strong static type guarantees whereas Dalvik bytecode may share registers across multiple types in some circumstances. Therefore, Soot will not simply translate a register into a local, but will perform splitting and some optimizations that are prerequisites to even being able to assign valid types to locals. For not having messy code and to simply downstream analyses, Soot will also simplify the code.

In total. even if you don't have an alias in the original program, i.e., you always use the same variable, that might be a different story in Jimple.

As a general design paradigm, many algorithms in FlowDroid are modular. You can choose a non-standard callgraph algorithm, alias algorithm, path reconstructor, etc. All of them have their known advantages, disadvantages and limitations. With non-standard FlowDroid option, you might trigger a bug. However, you might also just run into a known pitfall for an algorithm you chose and that was maybe the reason why we selected a different algorithm as the default.

Some choices really depend on the use case. However, for aliasing, I would stick to the defaults.