Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Google interpelle Samsung à la suite de changements « inutiles » apportés dans le noyau d'Android
Et qui ont créé des failles sur le Samsung Galaxy A50

Le , par Olivier Famien

360PARTAGES

12  0 
Jann Horn, de l’équipe de sécurité Project Zero de Google, vient de publier des failles découvertes sur un des appareils mobiles de Samsung, le Galaxy A50. Cet appareil qui est sorti en 2019 fait partie du milieu de gamme des appareils de l’entreprise sud-coréenne. Il intègre un écran Super AMOLED de 6,4 pouces, trois caméras à l’arrière (de 5 Mpx, 25 Mpx et 8 Mpx), une caméra frontale de 25 Mpx et un lecteur d’empreinte placé sous l’écran. Selon le rapport de Horn, Samsung aurait pu éviter ces failles en cessant simplement d’ajouter certaines fonctionnalités personnalisées inutiles et qui plus est peuvent être supprimées sans perte de valeur sur l’appareil.

Pour mieux comprendre les déclarations du membre de l’équipe de Project Zero, il convient de jeter un coup d’œil dans l’implémentation des fonctionnalités propres à chaque appareil. Lorsque les fournisseurs de mobiles Android mettent un appareil sur le marché, il est fréquent qu’ils ajoutent du code spécifique au noyau du système de l’appareil. Dans de nombreux cas, ces modifications sont importantes, voire nécessaires pour le bon fonctionnement de l’appareil commercialisé. Samsung qui ne déroge pas à la règle a également apporté moult changements dans le noyau d’Android pour ce qui concerne son Galaxy A50. Mais comme Horn le signale, ces changements entraînent souvent des failles de sécurité.


Sur le Galaxy A50 (modèle modèle SM-A505F), un tas de code spécifique a été ajouté au noyau de l’appareil, notamment dans le volet sécurité/arborescence. En particulier, security/proca/ est un code spécifique de Samsung qui implémente « ;Process Authenticator ;». Selon les déductions de Horn, ce code serait utilisé pour suivre l’état d’authentification des processus en fonction de l’exécutable qu’ils exécutent, en utilisant des attributs étendus pour décrire les contextes de sécurité des fichiers exécutables, puis en mettant ces informations à la disposition du code de l’hyperviseur. Alors que certaines balises ont été implémentées afin de permettre à PROCA de suivre l’état des tâches en cours d’exécution, il apparaît que dans son fonctionnement, PROCA peut être leurré.

En effet, lorsque l’état d’une tâche passe à TASK_DEAD, le PID numérique de cette tâche est publié. Cela arrive avant que son TASK_STRUCT disparaisse. Par conséquent, lorsqu’une tâche authentifiée meurt, le PID numérique (que PROCA utilise pour identifier les tâches suivies) peut être réutilisé alors que l’entrée PROCA pour le PID est toujours présente. Au-delà des implications logiques pour la sécurité (pouvoir passer les vérifications d’authentification en réutilisant le PID d’une tâche authentifiée, morte et non libérée), cela signifie que via clone (), il est possible d’insérer des clés en double dans le hashmap, puis effectuer des suppressions simultanées sur la même clé, ce qui conduit à une corruption de mémoire dans proca_table_remove_by_pid (). Et puisque le verrou est abandonné entre la recherche de hashmap et l’opération hashmap unlink, deux appels simultanés pour le même PID numérique peuvent provoquer des failles de type use-after-free et de double-free.

Comme autre modification apportée dans le noyau du Samsung Galaxy A50, Horn rapporte qu’une « ;protection ;» supplémentaire a été ajoutée aux structures d’informations d’identification. Struct cred a été porté en lecture seule à l’aide du code de l’hyperviseur (CONFIG_RKP_KDP, "Protection for cred structure", et les transitions vers l’UID 0 sont soumises à des vérifications spéciales basées sur le chemin de l’exécutable en cours. Mais aucune de ces modifications n’empêche réellement un attaquant qui a un contrôle suffisant sur le noyau de modifier les structures d’informations d’identification, de lire ou de modifier directement les données utilisateur.

Selon Horn, ces modifications de code ne font qu’ajouter une surface d’attaque supplémentaire. Il ajoute que certaines des fonctionnalités personnalisées ajoutées par Samsung sont inutiles et peuvent être supprimées sans perte de valeur. Bien que ne sachant pas de manière exhaustive ce que PROCA est censé faire, il souligne toutefois que SEC_RESTRICT_SETUID semble être conçu pour restreindre un attaquant qui a déjà acquis une lecture / écriture arbitraire du noyau — ce qui pour lui semble futile. Les ressources d’ingénierie auraient été mieux dépensées pour empêcher un attaquant d’atteindre ce point en premier lieu, soutient-il.

Comme recommandations, Horn préconise que les modifications spécifiques du noyau soient effectuées en amont ou déplacées dans des pilotes de l’espace utilisateur, où elles peuvent être implémentées dans des langages de programmation plus sûrs et/ou en bac à sable, et en même temps ne compliqueront pas les mises à jour des versions plus récentes du noyau. En outre, le fait qu’il ait pu réutiliser le bogue infoleak qui a été corrigé il y a plus d’un an montre pour lui que la façon dont les branches des appareils Android sont actuellement maintenues est un problème de sécurité. Alors qu’il a critiqué certaines distributions Linux dans le passé pour ne pas avoir pris les correctifs en amont en temps opportun, la situation actuelle dans l’écosystème Android est pire, selon le chercheur en sécurité. Idéalement, tous les fournisseurs devraient s’orienter vers les mises à jour fréquentes du noyau effectuées en amont et non chercher à implémenter leurs solutions personnalisées en aval, ce qui conduirait selon Horn à des bogues comme ceux découverts sur le Galaxy A50. Samsung a récemment publié une mise à jour de sécurité pour corriger les failles découvertes.

Source : Google Project Zero, Samsung

Et vous ?

Quels commentaires faites-vous de ces failles ;?

Selon vous, ces failles sont-elles une conséquence de l’open source ;?

Quelles solutions suggérez-vous pour éviter ce genre de vulnérabilités ;?

Voir aussi

Sécurité : Google corrige une faille critique qui permet l’installation de malwares via le sous-système Bluetooth d’Android sans intervention du possesseur du smartphone
Certains téléphones Android peuvent être piratés à distance en utilisant une image PNG, comme l’indique le dernier bulletin de sécurité Android
Pour déverrouiller un smartphone Android, un attaquant n’a qu’à répondre à un appel via l’appli Skype, un correctif est disponible, mais...
Google, Samsung, Xiaomi, Huawei et autres affectés par une faille zéro-day dans le système d’exploitation mobile Android, qui déverrouille l’accès root des appareils cibles
Une faille dans Android permet à un attaquant d’enregistrer l’activité de l’écran et l’audio système, Lollipop, Marshmallow et Nougat concernés

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de earhater
Membre éclairé https://www.developpez.com
Le 17/02/2020 à 10:04
En effet, lorsque l’état d’une tâche passe à TASK_DEAD, le PID numérique de cette tâche est publié. Cela arrive avant que son TASK_STRUCT disparaisse. Par conséquent, lorsqu’une tâche authentifiée meurt, le PID numérique (que PROCA utilise pour identifier les tâches suivies) peut être réutilisé alors que l’entrée PROCA pour le PID est toujours présente. Au-delà des implications logiques pour la sécurité (pouvoir passer les vérifications d’authentification en réutilisant le PID d’une tâche authentifiée, morte et non libérée), cela signifie que via clone (), il est possible d’insérer des clés en double dans le hashmap, puis effectuer des suppressions simultanées sur la même clé, ce qui conduit à une corruption de mémoire dans proca_table_remove_by_pid (). Et puisque le verrou est abandonné entre la recherche de hashmap et l’opération hashmap unlink, deux appels simultanés pour le même PID numérique peuvent provoquer des failles de type use-after-free et de double-free.
A vos souhaits
2  0