brazdil / dexter

1 stars 1 forks source link

Taint object assigned too late for external classes #9

Open brazdil opened 11 years ago

brazdil commented 11 years ago

Example:

new-instance v0, Ljava/util/ArrayList;
# ideally now want to create a new TaintExternal object
# but v0 cannot be referenced at this point
# so could create it but not cache it
const v1, 0xA
invoke-direct {v0, v1} Ljava/util/ArrayList;-><init>(I)V
# now v0 becomes valid, but it might be too late
# what if the constructor calls some internal code?
brazdil commented 11 years ago

Thinking aloud, the scenario I'm worried about is this:

This directly applies to callbacks as well. The typical example I had in the dissertation was:

myListener = new LocationListener() { 
    public void update(Location loc) { /* do stuff */ } 
};
locationManager.registerListener(myListener};

locationManager is tainted, ergo the recursive setTaint method is called on myListener just before it is registered. All that's fine, but we're lacking a mechanism that would propagate it into update. Some sort of "if called from external source assign this to all your parameters" thing... Not sure what the right answer is though.

On second thought... both examples can be solved quite simply. The listener class inherits Object and therefore must have a t_super field inside (holds taint of the external parent, every internal class must have one; see the wiki), same goes for the internal object in the constructor example. This field will receive the correct taint before the problematic methods are called. So in case of a method having been entered from an external origin, could we just pull the taint from there and assign it to all the arguments? Do we do the same for internal origin? Don't see a reason... Just need to be careful to use t_super when a method is called on the parent.