[Soot-list] FlowDroid: call graph doesn't look context sensitive

[Steven Arzt]

Hi Denis,

 

I‘ m not totally sure about the state of Paddle in Soot. Somehow, it never made it as the new default callgraph builder though it was originally intended to be a more modern replacement. I guess there were just not enough cases of false positives due to context-insensitivity to make people go that extra mile and enable and configure Paddle. Honestly, I have never used Paddle ^^

 

Best regards,

  Steven

 

Von: Denis Bogdanas [mailto:denis.bogdanas at gmail.com] 
Gesendet: Freitag, 4. März 2016 23:59
An: Steven Arzt
Cc: soot-list at cs.mcgill.ca
Betreff: Re: [Soot-list] FlowDroid: call graph doesn't look context sensitive

 

Hi Steven,
Makes sense now.

What was the reason you didn't use Paddle in FlowDroid? Was it scalability?

 

On 4 March 2016 at 01:41, Steven Arzt <Steven.Arzt at cased.de> wrote:

Hi Denis,

 

Now I understand your question. This was actually my mistake. If you only take FlowDroid to construct the dummy main method which is then fed into Soot for generating the callgraph for your app, it will, by default, use SPARK, which is context-insensitive. There is only one node for Thread.run() and this has outgoing edges to whatever any instance of Thread can call in its run() methods. That’s by design. You can also try to use Soot’s Paddle instead of SPARK to have a context-sensitive callgraph, but that’s not supported by default. If you are willing to implement and test it, feel free to share your code changes with the community. There is already a switch for using different callgraph algorithms in FlowDroid (CHA, RTA, VTA, full-blown SPARK), an option for Paddle would fit in there quite nicely.

 

Now for the source of the misunderstanding. FlowDroid propagates the types of tainted objects during taint propagation. If you call a method on a tainted object, it will filter all edges from the callgraph that do not match the type information in the taint abstraction. If you, for instance, store tainted data in your anonymous Runnable instance and then access it from sensitive(), FlowDroid will be able to distinguish the two different anonymous Runnable classes due to the type information propagated along with the taint. That#s something we built on top of the context-insensitive callgraph to improve precision.

 

Best regards,

  Steven

 

Von: Denis Bogdanas [mailto:denis.bogdanas at gmail.com] 
Gesendet: Freitag, 4. März 2016 00:15
An: Steven Arzt
Cc: soot-list at cs.mcgill.ca
Betreff: Re: [Soot-list] FlowDroid: call graph doesn't look context sensitive

 

Also please notice the format: those are all SootMethod. Shouldn't they be MethodContext?

 

On 3 March 2016 at 15:13, Denis Bogdanas <denis.bogdanas at gmail.com> wrote:

Hi Steven,

Default settings produce the same result. From my logs:

>From <edu.oregonstate.ex.flowdroidtest.TestActivity: void onCreate(android.os.Bundle)>
  to <edu.oregonstate.ex.flowdroidtest.TestActivity: void sensitive()>
--------------------------------------------
<edu.oregonstate.ex.flowdroidtest.TestActivity: void onCreate(android.os.Bundle)>
<edu.oregonstate.ex.flowdroidtest.TestActivity: void threadWithSensitive()>
<java.lang.Thread: void run()>
<edu.oregonstate.ex.flowdroidtest.TestActivity$3: void run()>
<edu.oregonstate.ex.flowdroidtest.TestActivity: void access$000(edu.oregonstate.ex.flowdroidtest.TestActivity)>
<edu.oregonstate.ex.flowdroidtest.TestActivity: void sensitive()>

>From <edu.oregonstate.ex.flowdroidtest.TestActivity: boolean onOptionsItemSelected(android.view.MenuItem)>
  to <edu.oregonstate.ex.flowdroidtest.TestActivity: void sensitive()>
--------------------------------------------
<edu.oregonstate.ex.flowdroidtest.TestActivity: boolean onOptionsItemSelected(android.view.MenuItem)>
<edu.oregonstate.ex.flowdroidtest.TestActivity: void emptyThread()>
<java.lang.Thread: void run()>
<edu.oregonstate.ex.flowdroidtest.TestActivity$3: void run()>
<edu.oregonstate.ex.flowdroidtest.TestActivity: void access$000(edu.oregonstate.ex.flowdroidtest.TestActivity)>
<edu.oregonstate.ex.flowdroidtest.TestActivity: void sensitive()>

Paths are produced by navigating the call graph upwards until a callback is reached. FlowDroid and soot on my machine are 2 weeks old.

 

On 3 March 2016 at 14:28, Steven Arzt <Steven.Arzt at cased.de> wrote:

Hi Denis,

 

You don’t actually need an implementation of java.* in your Android platform JAR file, because FlowDroid provides explicit models for threads. If you use FlowDroid’s default models, your callgraph should be able to distinguish the two calls, i.e., there should not be a path from emptyThread() to sensitive(). You have two different instances of the Thread class, two different implementations (and thus also instances thereof) of Runnable, and I don’t see any good reason for FlowDroid to combine the two paths.

 

Best regards,

  Steven

 

Von: soot-list-bounces at CS.McGill.CA [mailto:soot-list-bounces at CS.McGill.CA] Im Auftrag von Denis Bogdanas
Gesendet: Donnerstag, 3. März 2016 23:04
An: soot-list at CS.McGill.CA
Betreff: [Soot-list] FlowDroid: call graph doesn't look context sensitive

 

Suppose we have 2 threads called from 2 UI callbacks. One of them calls method sensitive(), another one is empty. In the call graph, both events will have a path to sensitive(), as if the two Thread instances were modeled as one:

protected void onCreate(Bundle savedInstanceState) {
    threadWithSensitive();
}

@Override
public boolean onOptionsItemSelected(MenuItem item) {
    emptyThread();
    return false;
}
private void threadWithSensitive() {
    new Thread(new Runnable() {
        public void run() {
            sensitive();
        }
    }).start();
}

private void emptyThread() {
    new Thread(new Runnable() {
        public void run() { }
    }).start();
}

Shouldn't only onCreate() lead to sensitive() ?

My setup: a crafted android.jar that has stubs for android classes but full implementation for java.* and javax.* packages.

 

I also noticed that class MethodContext which is supposed to model a method in its context, is never instantiated, regardless of what call graph algorithm I use.

What am I missing?

thanks,

-- 

Denis





-- 

Denis




-- 

Denis




-- 

Denis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20160305/e74f91ee/attachment-0001.html