Exploiting checkCallingOrSelfPermission() for privilege escalation attack

Question

I was going through checkCallingOrSelfPermission() in the Context class and wondering how it can be exploited; i.e. if some application triggers a method of the callee/your application which in turn calls checkCallingOrSelfPermission(), finally giving access to that permission to the other application, or releasing sensitive information that would otherwise require that permission.

This is what i understood after going through the Java Doc:

This method can be only exploited by any calling application which is in the same process of callee application. To get into the same process both the apps need to have the same shareuserid and process in the manifest file, in addition to also being signed by the same certificate.

So the calling application needs to do following.

1. Has to know under which process and shareuser id the callee application is running. (I'm not sure how feasible this is?)

2. Has to be signed with the same certificate that the callee application was signed with (unlikely assuming the certificate is kept safe).

Is this the method of exploitation that the checkCallingOrSelfPermission() documentation is warning against, or are there other (more realistic) ways that it could be exploited.

I also checked this post, but the answer was not satisfactory.

Answer 1

Under normal circumstances Binder.callingPid() == Process.myPid() holds. This changes when handling an IPC request, the system modifies the calling PID value stored by Binder, it assigns it to the PID of the caller app. However, this change only affects the thread where the remotelly called method is executed, in other threads the equality still holds. Therefore, if checkCallingOrSelfPermission() is called in a such an unaffected thread, it will return PERMISSION_GRANTED (provided the service app holds that permission) and a leak (or other biblical consequences) may occur.

Alternatively, if clearCallingIdentity() is called before checkCallingOrSelfPermission() the same issue can arise, although I believe it is less likely to happen.

Tested on Nexus 6P, Android 6.0.1 (MHC19I).