Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Taint object assigned too late for external classes #9

Open
brazdil opened this issue Jul 31, 2013 · 1 comment
Open

Taint object assigned too late for external classes #9

brazdil opened this issue Jul 31, 2013 · 1 comment

Comments

@brazdil
Copy link
Owner

brazdil commented Jul 31, 2013

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
Copy link
Owner Author

brazdil commented Jul 31, 2013

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

  • call a constructor of an external class with an internal object parameter and a tainted primitive (won't work with a tainted object)
    • this already combines taint of args, so the internal object will get its fields tainted
  • the constructor takes the tainted primitive and stores it inside a field accessible through a getter
  • the constructor calls a method of the parameter object (even something stupid like equals), passing its reference to it
    • at that point, the this reference is already valid, but not tainted
    • the internal method has its fields tainted, but can access the primitive through the untainted ref

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant