2013-09-02 13 views
10

Die aktuelle Android Permission System causes the following issue:verändern Programmatically Manifest - Android benutzerdefinierte Berechtigungen

App A definiert die benutzerdefinierte Berechtigung von:

com.package.permission.READ_APP_DATA 

Wenn App B die benutzerdefinierte Berechtigung installiert wird erklärt, es gewährt wird.

Wenn jedoch App A nach App B installiert ist, dann ist die Genehmigung ist nicht B. App gewährt

Während dies kein gemeinsames Auftreten sein können, aufgrund App B oft ein Plugin zu sein von App A kann es natürlich vorkommen und tut es für meine Bewerbung.

Mit SuperUser-Anwendungen, die zustimmen, die globale benutzerdefinierte Berechtigung von android.permission.ACCESS_SUPERUSER einzuführen, kann dies ein großes Problem sein, sollte sich ein Benutzer entscheiden, die SuperUser-App zu wechseln.

Um das Problem zu umgehen, beabsichtige ich den folgenden Code in meiner Anwendung für die benutzerdefinierte Erlaubnis verwenden ich bin erklärt zu starten:

checkPermissions(this, getCallingActivity().getPackageName()); // get the package name from the sender first 

private boolean checkPermissions(Context context, String callingPackage) { 

    final List<PackageInfo> apps = context.getPackageManager().getInstalledPackages(PackageManager.GET_PERMISSIONS); 

    for (PackageInfo pi : apps) { 

     if (pi.packageName.equals(callingPackage)) { 

      String[] permissions = pi.requestedPermissions; 

      if (permissions != null) { 
       for (String permission : permissions) { 
        if (permission.equals("com.package.permission.READ_APP_DATA")) { 
         return true; 
        } 
       } 
      } 
     } 
    } 
    return false; 

Gemäß dem Titel dieser Frage: Ist diese Methode 'sicher'? Oder ist es eine Möglichkeit,/root-Hack, der eine Anwendung manifestiert geändert werden könnte, nachdem es installiert ist und die Erlaubnis programmatisch ‚hinzugefügt‘ zu App B?

+1

"Wenn App A jedoch nach App B installiert wird, wird App B nicht die Berechtigung erteilt." - in beiden Apps das gleiche '' Element haben, insbesondere wenn es sich um eine Berechtigung auf Signaturebene handelt. – CommonsWare

+0

@CommonsWare - Danke. Könnten Sie das vielleicht bitte erläutern? Ich glaube, das ist bereits, was ich mache, aber App B-Berechtigungen werden immer noch nicht erkannt/gewährt. Mir ist aufgefallen, dass der verlinkte Fehlerbericht endlich als defekt gemeldet wurde. – brandall

+1

"Ich glaube, das ist bereits, was ich tue" - Ihre Frage zeigt an, dass nur App A ein "" Element hat und dass App B nur ein '' Element hat. Ich sage, dass das '' Element auch zu App B hinzugefügt werden soll, so dass die Installationsreihenfolge keine Rolle mehr spielt. – CommonsWare

Antwort

9

Ich bin nicht sicher, ob ich die Frage richtig hinzubekommen, wie ich weiß nicht, wie man eine Erlaubnis in die manifeste Hacking nach Connects, um den Code installieren Sie oben gepostet. Aber Ihren letzten Absatz zu beantworten:

nicht auf einfache Art und Weise. Der Nutzer muss eine Mod auf seinem Gerät installiert haben, die während der App beliebige Berechtigungen gewähren kann, während die App sie anfordert. IIRC die Manifestdatei selbst wird nur zur Installationszeit analysiert.

Also, was wir in einem mod verwendet wird, die Änderung der Methode grantPermissionsLPw in Klasse com.android.server.pm.PackageManagerService.

Es wird verwendet, eine Trägerrakete die Erlaubnis android.permission.EXPAND_STATUS_BAR zu gewähren, die es nicht in seinem Manifest erklärt hat.

Ich bin aber nicht sicher, ob dies jemals für Ihre Anwendung verwendet werden würde. Aber um es zusammenzufassen: Wenn der Benutzer einer App eine arbitray gewähren möchte, benutzerdefinierte Erlaubnis: Ja, es ist möglich.

UPDATE

ich ein bisschen mehr, natürlich erarbeiten können. Ich kann zwei Szenarien sehen

1. Statische mod geschieht

Die oben erwähnte Klasse in services.jar befindet. Wie wir wissen, können Dateien wie diese dekompiliert, geändert und neu kompiliert werden. Eigentlich ist es eine ziemlich einfache Bearbeitung dieser Datei. Ich weiß nicht, wie ich das direkt am Telefon machen könnte, aber ich würde es für möglich halten. Es ist einfach nicht machbar, dass weit verbreitete Lösungen verfügbar sind, da es eine gute Verarbeitungsleistung benötigt. Ein Angreifer kann nicht nur eine universelle Datei bereitstellen. Diese Dateien ändern sich von Gerät zu Gerät und auch zwischen Firmware-Versionen.Entweder muss der Angreifer eine große Menge an gepatchten Dateien bereitstellen oder das Patching live durchführen, indem er es auf einen Server hochlädt, es patcht, erneut herunterlädt und es installiert. Dieses Szenario ist nicht sehr wahrscheinlich, wenn Sie mich fragen.

2. dynamischer mod

Es gibt mehr als einen Rahmen zur Verfügung, die Prozesse erlauben zu verändern, während sie opertae. Die beliebteste von ihnen ist die Xposed Framework. Grundsätzlich ist es eine gepatchte app_process und eine entsprechende API, die Reflection nutzt, um laufende Prozesse zu ändern. Jetzt kann ein Angreifer seine App mit diesem Framework versenden und mit Root-Zugriff stillschweigend installieren. Mit Root-Zugriff kann er das Modul sogar selbst aktivieren, was normalerweise eine Benutzerinteraktion erfordert. Sobald ein solches Modul aktiviert ist, kann sich der Angreifer in die oben genannte Methode einklinken und die angeforderten Berechtigungen ändern. Er würde dies tun, indem er das Objektfeld, das die angeforderten Berechtigungen enthält, erhält, das gewünschte Objekt hinzufügt, DANN die ursprüngliche Methode ausführen, die die ursprünglich definierten Berechtigungen hinzufügt.

Bitte beachten Sie, dass beide Szenarien erfordern, dass der Benutzer die schädliche App selbst installiert. Du hast nicht erwähnt, wofür deine App ist, also kann ich dir nicht wirklich helfen, das Risiko zu bewerten. Alles was ich sagen kann ist, dass ein Angreifer solche Dinge tun kann.

+0

Danke für deine Antwort - Würdest du in der Lage sein, zu erklären, wie der Mod funktioniert bitte? Es würde mir helfen, das "Risiko" zu verstehen. – brandall

+0

Bitte beachten Sie das Update oben. Korrigiert den Klassennamen auch. Wenn Sie weitere Fragen haben, zögern Sie nicht zu fragen. – langerhans

+1

Danke für das Update, es ist wirklich hilfreich und einige gute verlinkte lesen. Ich werde zurückkehren, um deine Antwort als korrekt zu markieren und dir die Belohnung für deine Bemühungen zu geben. – brandall

0

Ich sehe ein Problem, wenn App A vor App B installiert ist und das Element <permission> in App A nicht deklariert ist, wird der Benutzer die Berechtigungsanfrage nie sehen. Wenn Sie jedoch das Element <permission> in App A verwenden müssen, könnte ein ähnlicher Ansatz verwendet werden, um zu überprüfen, ob die dem Benutzer angezeigte Bezeichnung und Beschreibung korrekt sind.

Verwandte Themen