[Soot-list] Flowdroid cannot identify simple password text flow
flanker017
flankerhqd017 at gmail.com
Tue Dec 16 01:23:52 EST 2014
Hi list:
Sam's approach is a rather good one, currently I'm also using
bodytransformer to patch the jimple body, by simply adding callback
invocation statement after the setCallback statement, i.e.
setOnClickListener. Not precise but simple to implement.
Thanks for steven and sam, johannes' discussions
2014-12-16 1:40 GMT+08:00 Steven Arzt <Steven.Arzt at cased.de>:
>
> Hi Sam,
>
>
>
> Thanks for the suggestion, that’s actually a pretty neat idea. Let’s hope
> that I find an hour or so to properly implement this in FlowDroid in the
> next days.
>
>
>
> Best regards,
>
> Steven
>
>
>
>
>
> *Von:* Sam Blackshear [mailto:sam.blackshear at gmail.com]
> *Gesendet:* Montag, 15. Dezember 2014 18:33
> *An:* Steven Arzt
> *Cc:* Johannes Lerch; soot-list at cs.mcgill.ca; flanker017
>
> *Betreff:* Re: [Soot-list] Flowdroid cannot identify simple password text
> flow
>
>
>
> Hi Steven,
>
> I had the same problem with capturing the context of anonymous inner
> class callbacks in my Droidel <https://github.com/cuplv/droidel> tool,
> but I was able to address this issue using a fairly simple hack. For the
> example above, I have an automated bytecode transformation pass that looks
> for inner class callbacks and transforms code like the example above to
> (effectively) be:
>
>
>
> onCreate() {
>
> final EditText passview = (EditText) findViewById(R.id.editText1);
> //password view
>
> Button button = (Button) findViewById(R.id.button1);
>
> OnClickListener listener = new OnClickListener() {
>
> @Override
>
> public void onClick(View v) {
>
> Log.d("log", passview.getText().toString());
>
> }
>
> });
>
> dummyMainClass.extracted_1 = listener // added via bytecode
> transformation
>
> button.setOnClickListener(listener)
>
> }
>
>
>
> The extracted_1 variable is an autogenerated public static field belonging
> to my harness class dummyMainClass. In the code for my dummyMainClass
> harness, I do the following
>
>
>
> public static OnClickListener extracted_1;
>
>
>
> Activity a = ...
>
> a. onCreate();
>
> if (*) extracted_1.onClick();
>
> ...
>
>
>
> This faithfully models invoking the callback in its actual context, and
> makes sure the fields/final local variables of the enclosing class/method
> that are read in the callback contain the proper values.
>
>
>
> - Sam
>
>
>
> - Sam
>
>
>
> On Mon, Dec 15, 2014 at 10:20 AM, Steven Arzt <Steven.Arzt at cased.de>
> wrote:
>
> Hi Johannes,
>
>
>
> I was imprecise in my last e-mail: The inner class as such is not the
> problem, but the fact that the inner class is being used as a callback. If
> the enclosing method would directly call a method on the inner class, we
> wouldn’t be in an any trouble at all. So we do support inner classes, but
> not inner classes as callbacks that access stuff from the enclosing method.
> Here’s why:
>
>
>
> This happens because we treat onClick like all other callbacks that can
> happen in the Android operating system. To us, there is (almost) no
> difference between a callback that notifies us of an incoming text message
> and a callback that notifies us of a button click. Therefore, we assume
> that such events can happen at every time.
>
>
>
> When generating the dummy main method, we exploit this assumption. The
> dummy main method emulates every possible order of callback method
> invocations:
>
>
>
> lbl: If (opaque) a.onClick();
>
> If (Opaque) goto lbl;
>
>
>
> This however means that there is one big list of callbacks to be triggered
> at every possible point in time. There is no more mapping between the
> callback and its context – the dummy main method simply does not express
> any relationship between the inner class implementing the onClick and its
> enclosing method any more. For the dummy main method, this is just some
> random class implementing some random callback.
>
>
>
> To treat such accesses properly, we would have to somehow ensure a correct
> taint propagation between the enclosing method and the callback in the
> inner class which might run at a totally different position in the hosting
> component’s lifecycle. We would then need to model that the enclosing
> method runs only once at a very precise point in time, but the contents of
> some variable live longer and may be accessed at any arbitrary point in
> time.
>
>
>
> Best regards,
>
> Steven
>
>
>
> *Von:* Johannes Lerch [mailto:lerch at st.informatik.tu-darmstadt.de]
> *Gesendet:* Montag, 15. Dezember 2014 18:13
> *An:* Steven Arzt
> *Cc:* 'flanker017'; soot-list at CS.McGill.CA
> *Betreff:* Re: [Soot-list] Flowdroid cannot identify simple password text
> flow
>
>
>
> Hi Steven,
>
> can you write some more words why "Anonymous inner classes are supposed
> not to access any final fields of their enclosing methods"? This is not
> apparent to me.
> Maybe you can as well elaborate why this is a challenge for FlowDroid.
> What is different to other fields? Is it because of the representation in
> byte code or Jimple?
>
> Regards,
> Johannes
>
> Am 15.12.14 17:09, schrieb Steven Arzt:
>
> Hi,
>
>
>
> This one of the loose ends we still have. Anonymous inner classes are
> supposed not to access any final fields of their enclosing methods. This is
> on the long list of possible enhancements we can still do at some point. It
> has nothing to do with password fields or UI elements in general – that
> could also be a getDeviceId() or anything else.
>
>
>
> By the way, I am currently looking for a student who wants to work on
> integrating a more precise sink model into FlowDroid; I’m sure you remember
> the conversation we had on this. Hopefully, I’ll find someone decent and we
> can make progress on that.
>
>
>
> Best regards,
>
> Steven
>
>
>
> *Von:* soot-list-bounces at CS.McGill.CA [
> mailto:soot-list-bounces at CS.McGill.CA <soot-list-bounces at CS.McGill.CA>] *Im
> Auftrag von *flanker017
> *Gesendet:* Montag, 15. Dezember 2014 15:16
> *An:* soot-list at cs.mcgill.ca
> *Betreff:* [Soot-list] Flowdroid cannot identify simple password text flow
>
>
>
> Hi:
>
>
>
> For the following code snippets:
>
>
>
> final EditText passview = (EditText)
> findViewById(R.id.editText1); //password view
> Button button = (Button) findViewById(R.id.button1);
> button.setOnClickListener(new OnClickListener() {
>
> @Override
> public void onClick(View v) {
> Log.d("log",
> passview.getText().toString());
> }
> });
>
>
>
> FlowDroid cannot identify the flow. DroidBench also doesn't cover this
> indirect case. If I move Log.d outside the onClick directly after passview
> assignment, FlowDroid would find the flow.
>
>
>
> Command line options are: java -cp
> soot-trunk.jar:soot-infoflow.jar:soot-infoflow-android.jar:slf4j-api-1.7.5.jar:slf4j-simple-1.7.5.jar:axml-2.0.jar
> soot.jimple.infoflow.android.TestApps.Test sample.apk PLATFORM_DIR
>
>
>
> No optimization options enabled.
>
>
>
> Would someone kindly look into this? Test apk attached at
> http://box.myqsc.com/-16232127
>
>
>
> _______________________________________________
>
> Soot-list mailing list
>
> Soot-list at CS.McGill.CA
>
> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
>
>
>
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at CS.McGill.CA
> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
>
>
>
--
Sincerely,
Flanker He (a.k.a. Qidan He)
Website: http://flanker017.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20141216/ebd1189e/attachment-0001.html
More information about the Soot-list
mailing list