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

Denis Bogdanas denis.bogdanas at gmail.com
Fri Mar 4 17:59:28 EST 2016


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/20160304/2129feb2/attachment.html 


More information about the Soot-list mailing list