Ich habe checkCallingOrSelfPermission () in der Context-Klasse durchlaufen und mich gefragt, wie es ausgenutzt werden kann; d. h., wenn eine Anwendung eine Methode des Angerufenen / Ihrer Anwendung auslöst, die wiederum checkCallingOrSelfPermission () aufruft, um schließlich der anderen Anwendung Zugriff auf diese Berechtigung zu gewähren oder vertrauliche Informationen zu veröffentlichen, für die diese Berechtigung andernfalls erforderlich wäre.
Das habe ich nach dem Java Doc verstanden:
Diese Methode kann nur von jeder aufrufenden Anwendung ausgenutzt werden, die sich im selben Prozess der aufgerufenen Anwendung befindet. Um in den gleichen Prozess zu gelangen, müssen die Apps in der Manifest-Datei die gleichen Freigabe- und Prozessfreigaben haben und zusätzlich vom selben Zertifikat signiert sein.
Also muss die aufrufende Anwendung folgendes tun:
Muss wissen, unter welchem Prozess und welcher sharebuser ID die aufgerufene Anwendung läuft. (Ich bin mir nicht sicher, wie machbar das ist?)
Muss mit demselben Zertifikat signiert sein, mit dem die aufgerufene Anwendung signiert wurde (unwahrscheinlich, dass das Zertifikat sicher aufbewahrt wird).
Ist dies die Auswertungsmethode, vor der die checkCallingOrSelfPermission () -Dokumentation warnt, oder gibt es andere (realistischere) Möglichkeiten, wie diese ausgenutzt werden könnten.
Ich habe auch diesen Beitrag geprüft, aber die Antwort war nicht zufriedenstellend.
Unter normalen Umständen Binder.callingPid() == Process.myPid() gilt. Dies ändert sich bei der Bearbeitung einer IPC-Anfrage, das System ändert den aufrufenden PID Wert, der von Binder gespeichert wurde, und ordnet es der PID der aufrufenden App zu. Diese Änderung wirkt sich jedoch nur auf den Thread aus, in dem die Remotellaufmethode ausgeführt wird , in anderen Threads gilt die Gleichheit weiterhin. Wenn also checkCallingOrSelfPermission() in einem solchen nicht betroffenen Thread aufgerufen wird, wird PERMISSION_GRANTED zurückgegeben (sofern die Service-App diese Berechtigung besitzt) und es kann zu einem Leck (oder anderen biblischen Konsequenzen) kommen.
Alternativ, wenn clearCallingIdentity() vor checkCallingOrSelfPermission() aufgerufen wird, kann das gleiche Problem auftreten, obwohl ich glaube, dass es weniger wahrscheinlich ist.
Getestet auf Nexus 6P, Android 6.0.1 (MHC19I).
Alles steht im Code.
Die checkCallingOrSelfPermission () ist sicher im IPC-Aufruf. Überprüfen Sie die Implementierung von checkCallingOrSelfPermission() und checkCallingPermission() hier . Beide prüfen die Erlaubnis des IPC-Clients / des Anrufers. Wenn der Anrufer von außen kommt, sind sie genau gleich!
Wenn der Aufrufer von innen kommt (derselbe Prozess), kann jemand, der Code in Ihrem Prozess ausführen kann, bereits ausgenutzt werden. Keine Notwendigkeit,% code% erneut zu verwenden.
Tags und Links android android-permissions