Android : découverte d'une nouvelle vulnérabilité dans l'OS
Les applications des constructeurs seraient la cause de plusieurs failles

Le , par Cedric Chevalier, Expert éminent sénior
D’après les statistiques, Android est le système d’exploitation mobile le plus installé au monde. Une célébrité qui a fait de cette plateforme une cible de choix pour les hackers de tout genre.

Cette fois-ci encore, le mécanisme de vérification de l’intégrité des fichiers APK de la plateforme mobile de Google est mis en cause. La nouvelle vulnérabilité affecte toutes les versions d’Android antérieures à Kitkat.

Les fichiers APK sont en fait des fichiers ZIP qui possèdent en plus un répertoire spécial nommé « META-INF » qui contient les sommes de contrôle (Checksum) pour l’ensemble des fichiers de l’archive. Et puisque l’APK dérive du ZIP, il hérite de celui-ci tous les avantages et inconvénients.

La structure du format ZIP est redondante. C’est un réel atout puisqu’elle a donné la propriété aux fichiers ZIP de pouvoir être séparés en plusieurs archives distinctes qu’on peut alors reconstituer aisément par la suite. En effet, le format ZIP a été créé à l'époque où la disquette régnait en maîtresse sur le marché.

Dans l’en-tête d’un fichier ZIP, deux champs pointent sur la même information (l’endroit où commencent les données dans le fichier ZIP). Il s’agit des champs « Filename Length » et « Central Directory ».

Dans le cas d’Android, le code Java qui permet d’extraire les données de l’APK pour vérifier leur intégrité se sert de l’information contenue dans Central Directory, alors que le code qui permet d’installer et d’exécuter les données de l’APK utilise les informations contenues dans le champ « Filename Length ». En principe, elles devraient pointer sur l’exécutable de l’APK.

Cependant, un hacker peut insérer un malware dans un fichier APK normal et ensuite modifier l’information contenue dans le champ « Filename Length » de façon à ce que l’OS mobile charge son malware au lieu de l’exécutable légitime sans que le contrôle d’intégrité ne détecte un élément suspect.


Pour l’instant, seul KitKat propose une solution au problème. Les possesseurs des versions antérieures sont invités à faire une mise à jour vers KitKat ou encore à utiliser un antivirus.

Par ailleurs, la fragmentation de la plateforme mobile de Google serait aussi l’un des éléments qui provoquent les problèmes de sécurité auxquels font face les possesseurs de périphériques Android.

Des chercheurs du département d’informatique de l’université de Caroline du Nord l'ont prouvé. Ils ont mené une étude sur trois catégories d’applications pour 10 périphériques mobiles provenant de 5 constructeurs différents (2 périphériques par constructeur). Ce sont les AOSP (Android Open Source Project), les applications développées par différents constructeurs de périphériques Android, ainsi que celles développées par des tiers.

L’étude a révélé que les personnalisations que les constructeurs apportent aux applications pour leurs périphériques mobiles sont des sources génératrices de vulnérabilités pour l’OS. En effet, 85,78 % des applications testées avaient un niveau de privilège plus élevé que ce qu'il devait normalement être, et en plus, 64,71 % à 85 % des vulnérabilités détectées par les chercheurs étaient dues aux actions directes des personnalisations des constructeurs.

Source : Saurik, rapport PDF de l'étude

Et vous ?

Qu'en pensez-vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Paul TOTH Paul TOTH - Expert éminent sénior https://www.developpez.com
le 09/11/2013 à 6:07
en lisant la new je n'ai pas compris la faille, je me permet donc de la réexpliquer:

voici en gros la structure d'un fichier ZIP contenant un seul fichier
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
 PK34 // signature 
 TailleCompressée 
 TailleDecompressée 
 LongueurDuNom 
 "Le Nom" 
 "Les données du fichier" 
 --- 
 PK12 // signature 
 TailleCompressée 
 TailleDecompressée 
 LongueurDuNom 
 AdresseduPK12  
 "Le Nom"   
 --- 
 PK56 
 NombreDeFichiers 
 AdresseDuPremierPK12
la vérification du fichier se fait avec les données du PK56 et des PK12

le chargement se fait avec le PK34 qu'on peut donc hacker
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
 
 PK34 // signature 
 TailleCompressée DU VIRUS 
 TailleDecompressée DU VIRUS 
 LongueurDuNom + Longueur des données originale = adresse du virus 
 "Le Nom" 
 "Les données du fichier" // ne pas modifier pour que le PK12 les retrouve et les valide 
 "Les données du virus" 
...
le loader charge l'entête PK34, saute la longueur du fichier (et le fichier original) puis charge le virus.
Avatar de Cyrilh7 Cyrilh7 - Membre régulier https://www.developpez.com
le 20/11/2013 à 19:13
Oui la c'est très claire! Et ça fait très mal
Offres d'emploi IT
IAM international trainee (H/F)
Atos - Ile de France - Les Clayes-sous-Bois (78340)
Intégrateur sécurité des SI (H/F)
Atos - Ile de France - Les Clayes-sous-Bois (78340)
Conception - développement - déploiement solutions cloud - big data (H/F)
Atos - Midi Pyrénées - Toulouse (31000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil