[Soot-list] Flowdroid cannot identify simple password text flow

Mon Dec 15 12:40:19 EST 2014

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] 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> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20141215/ffeb4094/attachment-0001.html 