issues in InterAppCommunication category

[fgwei]

trafficstars

There are three test apps in such category, each of them have problems.

Echoer: no description at all. (should be 1 leakage path) SendSMS: no description at all. (should be 3 leakage paths) StartActivityForResult1: should have 4 leakage paths, but description only write 1.

[srasthofer]

Thx @fgwei @StevenArzt Was it the didfail-project contribution?

[fgwei]

And one more question. In ActivityCommunication2, I think we should also consider implicit ICC call as sink (since in other bench app we are considering such sink).Thus 2 leakage path instead of 1. ActivityCommunication4, ActivityCommunication8, BroadcastTaintAndLeak1, and UnresolvableIntent1 are the same as above

IntentSink2 I think are debatable, since you are considering explicit ICC as sink.

Hope I am not throwing so many questions. :-P

Thanks,

[uwinsoftware]

For ActivityCommunication2, what implicit Intent are you referring too? startActivity, i.e. startActivity(i)?

Because intent is fully resolved to a specific activity, so the extra flow you would get would be false positive.

[fgwei]

startActivity(i); at OurFlowActivity.java

But as it is an implicit call, outsider may get it, thus it is a sink.

[uwinsoftware]

Not really, only component registered with ACTION of "edu.mit.icc_action_string_operations" will get it. Which in this case is the InFlowActivity.

[fgwei]

But an attacker can also register an Action as "edu.mit.icc_action_string_operations", then get your intent.

[StevenArzt]

For ActivityCommunication2: That is indeed debatable. However, since we placed that app in the "InterComponentCommunication" folder, we aimed at communications inside one application, not between applications. That is, we make the assumption that there is no other app in our world. This under-approximation is somewhat in line with how many tools treat calls to native methods: Instead of assuming that they can taint everything, they assume these native calls to be no-ops to avoid a taint explosion.

With that reasoning, IntentSink2 is ok as it sees an intent communication without any receiver and treats this as a sink. In IntentSink2, the user can specify the target class name, so it can go anywhere an we don't even know one "internal" receiver.

IntentSource1 already has a single leak path. Did I miss anything?

The folder "InterAppCommunication" contains three apps which work together. With a similar closed-world assumption, only they communicate amongst themselves, leaving only the documented leak path.

In general, if you have a good reason, your analysis may always detect different leaks than the ones described in the DroidBench documentation and be totally fine with it. As long as you can explain why and have a good reason for it, that's ok. In the end, you have to say what your security property is.

It's pretty hard to have a policy that is at the same time consistent and still provides realistic results without over-tainting.

[fgwei]

That's a nice point. It is hard to have a consistent criteria. We should have some scope assumption, and have different defining of problem.

IntentSource1 has 2 leak paths, that was by mistake reported. I already move it out. Thanks,

[uwinsoftware]

Steve answered it well. For us when we did report, the implicit flow in ActivityCommunication2 was included in the explicit flow in the report so we didn't count them. We considered it a partial flow (A->B vs. A->B->C).

Plus, when multiple components register for the same action, then user will be prompted to select of what component to deliver the intent to. So user is a little bit aware of what app some information is flowing to.

[peteraldous]

There is still no leakage description in Echoer.