Universit Laval

VERS LAPPRIVOISEMENT DES ATTAQUES DELEVATION DE

PRIVILEGES SUR ANDROID


COURS DE SECURITE & METHODES FORMELLES
SYNTHESE DARTICLE

Sven Bugiel, Lucas Davi, Alexandra Dmitrienko, Thomas Fischer,Ahmad-Reza Sadeghi, Bhargava Shastry


TCHALLA Nina Essowaza
Baccalaurat Informatique







Charg du cours : Mohamed Mejri
Hiver 2013


SOMMAIRE

Table des figures ........................................................................................................................ 3
Introduction .............................................................................................................................. 4
Problmatique ........................................................................................................................... 4
I. Architecture dAndroid .................................................................................................... 4
Android, une pile logicielle ........................................................................................................... 4
Android, un bac sable ................................................................................................................. 5
Android, un systme de permission ............................................................................................. 5
II. Problmatique ................................................................................................................. 5
Classification des attaques et modles ennemi ...................................................................... 5
Objectifs et exigences ................................................................................................................... 6
Hypothses.................................................................................................................................... 7
III. Solution propos .......................................................................................................... 7
Prsentation gnrale ................................................................................................................... 7
Instanciation de la vue systme : reprsentation graphique ..................................................... 10
Reprsentation graphique de llvation de privilge ............................................................... 11
IV. Politique de scurit .................................................................................................. 12
V. Evaluation de lefficacit et de la performance ............................................................... 13
Mthodologie des tests .............................................................................................................. 13
Communication des applications tierces .................................................................................... 13
Efficacit ...................................................................................................................................... 13
Performance................................................................................................................................ 14
Conclusion ............................................................................................................................... 15
Vers lapprivoisement des attaques dlvation de privilges sur Android Hiver 2013
Rdig par Nina TCHALLA

Table des figures

Figure 1. Equipement internes dAndroid a) Pile logicielle dAndroid b) Canaux de
communication possibles ..................................................................................................................... 4
Figure 2. Classification des attaques dlvation de privilges de niveau-application .................... 6
Figure 3. Architecture du framework ............................................................................................... 8
Figure 4. Reprsentation graphique du systme ............................................................................ 10
Figure 5. Une rgle de scurit visant dfier les attaques de gestion malveillante dappels
tlphoniques ..................................................................................................................................... 12
Figure 6. Table 1 : Rsultats du chronomtrage des ICC Table2 : Rsultats du chronomtrage des
composants systme .......................................................................................................................... 14
Vers lapprivoisement des attaques dlvation de privilges sur Android Universit Laval -H2013
Rdig par Nina TCHALLA Scurit &mthodes formelles
4
Introduction
Google Android est lun des systmes dexploitation les plus rpandu au monde ; d fait quelle est
open source et quil est relativement facile de publier une application sur lAndroid Market. De ce
fait il est plus expos que les autres systmes dexploitation aux attaques. De plus, il a t prouv
quil tait plus vulnrable aux attaques de vice et de collusions dapplications qui sont tous
deux classes dans le groupe des attaques dlvation de privilge.
Ce document consistera faire une synthse de ltude qui a t mene et qui est dcrite dans cet
article ; tude qui consist plus exactement proposer une politique de scurit, un framework
qui permettra de contrer les attaques de privilges en gnral et en particulier les deux types
dattaques auxquels Android est le plus expos.
Nous allons donc prsenter dans un premier temps lobjet de cet article, Android. Ensuite, nous
montrerons les diffrents types dattaques dlvation de privilges, les modles ennemis dans
lesquelles ces attaques sont reconnaissables et enfin nous parlerons de la solution propos, son
architecture ainsi quune brve valuation sur sa performance et son efficacit

Problmatique
I. Architecture dAndroid
Android, une pile logicielle
Android est un systme open-source pour les quipements mobiles. Elle est construite au dessus
du noyau Linux et comporte une couche middleware et une couche application.


Figure 1. Equipement internes dAndroid a) Pile logicielle dAndroid b) Canaux de
communication possibles
Le noyau Linux offre les services systmes basiques aux couches suprieures tels que lisolation de
processus et lordonnancement, le support de systme de fichiers, les pilotes pour les
quipements et le rseau. La couche middleware inclue la machine virtuelle Dalvik (the Dalvik
Virtual Machine: DVM), des librairies natives et Java et fournit galement des services entre autre
Vers lapprivoisement des attaques dlvation de privilges sur Android Universit Laval -H2013
Rdig par Nina TCHALLA Scurit &mthodes formelles
5
la gestion du cycle de vie des applications. Cest galement cette couche qui se charge de fournir
un systme de contrle daccs mandat (Mandatory Access Control MAC) pour la communication
des applications. Tout en haut de larchitecture, on retrouve la couche application qui inclue
notamment les applications prinstalles.
De faon basique, les applications sont des composants. Android offre quatre types de
composants : les activits, les services, les fournisseurs de contenu et les rcepteurs de diffusion.
Les applications communiquent laide dun mcanisme offert par le middleware, la chaine
IPC (Communication Inter-Process). Les ICC (Communication Inter-Composants) sont des chanes
crs lorsque la communication entre deux composants applicatives est cre ; elles sont
diffrentes des IPCs au niveau de la couche Kernel de Linux. Les applications peuvent galement
communiquer au travers de canaux directement contrls par le Kernel ou via des sockets
internet.
Android, un bac sable
Pour la gestion de lexcution des applications et des processus, Android implmente le
SandBoxing. Un SandBox est un bac sable o les applications sexcutent en multi-process, mais
chacun sexcutant dans son processus en sisolant. Lorsquune application est lance, un
identifiant unique dutilisateur (UID) lui est attribue ainsi que des niveaux de permissions bien
dfinis. De ce fait, il ne peut accder qu ses propres ressources ou aux fichiers publics. Aucune
application ne peut sexcuter en tant quutilisateur root .
Android, un systme de permission
Android implmente un systme de scurit base sur les permissions o des ressources sensibles
telles que linterface dappel, laccs internet ou encore la liste de contact sont protgs par des
permissions. Il faut noter que la liste des permissions standards dAndroid contient 110 items.
Tout dveloppeur dapplication doit donc spcifier quelles sont les permissions requises pour
excuter son application. De plus il doit dfinir les permissions requises pour accder certaines
interfaces sensibles. Toutes ces dfinitions sont enregistres dans le fichier Manifest qui fait
partie du package dinstallation. Ces permissions sont demandes lutilisateur lors de
linstallation ; celui-ci peut soit les accorder (opration irrversible) soit annuler linstallation.
II. Problmatique
Classification des attaques et modles ennemi
Les attaques de privilges sont rparties en deux classes : les attaques de vice (confused
deputy attack) et les attaques de collusion dapplication (colluding application).
Le premier type dattaque concerne les applications malicieuses qui sappuient sur les interfaces
non protges dapplication bnignes. Les rsultats de rcentes recherches montrent quelle
concerne le plus souvent les applications par dfaut et les applications de la troisime couche.

Vers lapprivoisement des attaques dlvation de privilges sur Android Universit Laval -H2013
Rdig par Nina TCHALLA Scurit &mthodes formelles
6

Figure 2. Classification des attaques dlvation de privilges de niveau-application
Le deuxime type dattaque concerne les applications malicieuses qui se regroupent, mettent en
commun leurs permissions dans le but dobtenir un ensemble de permissions non autoris par
lutilisateur. Si on prend lexemple de lattaque dans le Soundcomber , une application a le droit
denregistrer laudio et de grer lactivit dappel tandis quune une seconde application possde
la permission Internet. Quand ces deux applications collusionne , ils peuvent capturer le
numro de carte de crdit (prononc par lutilisateur lors dun appel) et le communiqu
ladversaire distant. En gnral, les applications collusionnes peuvent communiquer soit
directement en tablissant un canal ICC direct, soit via une connexion socket tablie localement ou
indirectement en partageant par exemple des fichiers.
Les modles ennemis considrs comme fiables sont :
Le faible adversaire (WeakAdversary) : il est capable de lancer des attaques de vice
connues travers les canaux ICC
Ladversaire basique (BasicAdversary): il peut lancer toute sorte dattaque de vice,
incluant les attaques inconnues et les attaques travers les sockets internet.
Ladversaire avanc(AdvancedAdversary): il peux lancer nimporte quelle attaque de vice
et aussi les attaques (inconnues) de collusion qui oprent via les appels ICCs.
Ladversaire fort (StrongAdversary) peut lancer nimporte quelle attaque dlvation de
privilge (couche application) incluant les attaques de collusion qui oprent via les
communications indirectes, travers les communications internet.
Objectifs et exigences
Idalement, la solution propose serait de rsoudre le modle de StrongAdversary, et de discuter de du fait
qu'il ya plusieurs dfis de s'attaquer la conception et la mise en uvre d'un framework qui est la fois
gnral et fin. Une analyse trop grossire peut entraner des effets ngatifs, par exemple, des faux positifs,
ce qui limite la facilit d'utilisation, tandis que les solutions dattaque spcifiques sont videmment limites
et peuvent chouer vaincre d'autres attaques dans des scnarios ralistes. Par ailleurs, l'ide intuitive de
combiner les mcanismes de protections existantes dattaques spcifiques pourraient ne pas suffire non
plus, car ceux-ci peuvent ne pas tre compatibles les uns avec les autres.
Vers lapprivoisement des attaques dlvation de privilges sur Android Universit Laval -H2013
Rdig par Nina TCHALLA Scurit &mthodes formelles
7
Pour relever ces dfis, le framework aura besoin dtre configurable, flexible et adaptable pour
rpondre aux diffrents compromis entre la scurit et la convivialit. En particulier, nous avons
besoin d'une solution qui peut tre configur pour tre efficace dans les modles WeakAdversary,
BasicAdversary, AdvancedAdversary et StrongAdversary selon les exigences imposes par le
scnario sous jacent.
Des exigences on galement t mises sur ce que devra tre la solution propose :
un systme de protection-centrale parce dlguant l'application de la politique de scurit
aux applications est risqu puisque les applications elles-mmes pourraient tre
vulnrables ou mme malveillants (tant donn le grand nombre d'applications disponibles
sur le march),
la compatibilit du moment o la recompilation (dun certain nombre voire de toute) les
applications sur le march Android ne serait pas pratique,
et le faible impact sur les performances puisque dans les scnarios d'usages mobiles, la
performance gnrale impose en raison de mcanismes de scurit ne devrait pas
affecter la convivialit.
Hypothses
Dans la conception de la base informatique scurise, quelques hypothses ont t mises :
Le noyau de Linux et la couche middleware dAndroid sont considrs comme non
malveillants
Les applications par dfaut sont galement considres comme non malveillants mais
peuvent faire lobjet dune attaque de vice
Les applications par dfauts dAndroid peuvent souffrir dun dfaut de conception ce qui
peut autoriser des logiciels malveillants tablir des communications indirectes

III. Solution propos
Cette partie dcrit les diffrents composants du framework propose comme solution et la
manire dont ils interagissent les unes avec les autres. Elle montre galement la reprsentation
graphique de larchitecture.
Prsentation gnrale
Le framework de scurit effectue un suivi de l'excution et l'analyse des liens de communication
entre les applications afin d'empcher la communication potentiellement malveillante, le tout
bas sur une politique de scurit rseau-centrique dfini. Il est essentiellement invoqu lorsque
les applications tentent d'tablir une connexion ICC, des accs aux fichiers ou une connexion aux
sockets ; il valide donc si l'opration demande peut potentiellement tre exploite pour une
attaque d'lvation de privilges (bas sur la politique de scurit sous-jacente).
Vers lapprivoisement des attaques dlvation de privilges sur Android Universit Laval -H2013
Rdig par Nina TCHALLA Scurit &mthodes formelles
8

Figure 3. Architecture du framework
La figure ci-dessus illustre mieux larchitecture du framework propos. Dune faon gnrale, il
sappuie sur une solution antrieure, XManDroid, qui amliore le middleware dAndroid.
Dans ce paragraphe, nous allons montrer comment la solution procde pour renforcer la scurit
dAndroid. Nous allons donc dcrire les composantes du framework et leurs interactions dans
quelques scnarios tels que la gestion des appels ICC (tapes 1-11), la (ds) installation des
applications (tapes a-b), les oprations (cration, lecture, criture) sur les fichiers (tapes o y
et i - iv) et l'installation de la politique de scurit (tapes I III).
La gestion des appels ICC
Pendant lexcution, le framework intervient dans la gestion des appels ICC au travers de la chane
dactions suivante :
Etape 1 : tous les appels ICC sont intercepts par le ReferenceMonitor Android (tape 1).
Etape 2 : Le ReferenceMonitor Android obtient de la base de donnes AndroidPermissions les
informations sur les autorisations de la base de donnes et valide les attributions d'autorisation.
Etape 3 : Si le ReferenceMonitor permet un appel ICC de procder, il invoque DecisionEngine de
veiller ce que la communication est en outre conforme la politique de scurit du systme
sous-jacent.
Etape 4 : DecisionEngine demande en premier un enregistrement correspondant cet appel
particulier ICC partir de la base de donnes PolicyDecisions.
Vers lapprivoisement des attaques dlvation de privilges sur Android Universit Laval -H2013
Rdig par Nina TCHALLA Scurit &mthodes formelles
9
Etape 5 : Si un enregistrement correspondant est trouv, cela signifie qu'une dcision prise
antrieurement peut tre applique. Sinon, DecisionEngine enregistre une nouvelle dcision
fonde sur des donnes provenant AndroidPermissions, SystemPolicy (tape 6) et SystemView
(tape 7).
Etape 8 : Par la suite, la dcision rsultante est stocke dans la base de donnes PolicyDecisions.
Etape 9 : Et si elle est positive, SystemView est mis jour pour reflter le fait quune liaison de
communication existe entre les composantes d'applications A et B.
Etape 10 : En outre, DecisionEngine informe ReferenceMonitor sur la dcision qu'elle a prise,
Etape 11 : et ReferenceMonitor soit permet ou refuse l'appel ICC.
La (ds) installation des applications
La procdure d'installation implique le PackageManager standard dAndroid. Plus concrtement, il
extrait les autorisations d'application partir du fichier Manifest et les stocke dans la base de
donnes AndroidPermissions (tape a). En outre, PackageManager ajoute une nouvelle application
dans SystemView (tape b). Aprs la dsinstallation de l'application, PackageManager supprime
toutes les entres de l'application dsinstalle de la base de donnes AndroidPermissions (tape
a) et supprime l'application de SystemView (tape b).
Les oprations (cration, lecture, criture) sur les fichiers
Toutes les oprations sur les fichiers sont interceptes par le composant KernelMAC: un module
de contrle d'accs obligatoire dans le noyau Linux. Lorsqu'un fichier / socket est cre (tape o),
KernelMAC met jour SystemView en consquence (tape [) et excute l'action demande
(tape y). Sur la demande d'un accs en lecture des fichiers, dune connexion des sockets Unix
ou le raccordement une prise Internet local (tape i), KernelMAC regarde son fichier de politique
interne pour vrifier si l'opration demande peut tre autoris se poursuivre. Si une telle rgle
n'existe pas dans son fichier de politique interne, KernelMAC demande une dcision politique de
scurit de DecisionEngine (tapes ii et iii), et par la suite refuse ou accepte l'opration en
consquence (tape iv). En outre, KernelMAC pourrait tre charg de mettre en cache les
dcisions politiques (relay par DecisionEngine) dans son fichier de politique interne pour une
utilisation future. Cela rduit les cots de performance induits par les changements de contexte
entre le noyau et le middleware.
Installation de la politique de scurit
PolicyInstaller crit (met jour) les rgles de politique du systme dans la base de donnes
SystemPolicy (tape I). Ensuite, il supprime toutes les dcisions prcdemment prises par le
DecisionEngine, car celles-ci peuvent ne pas se conformer la nouvelle politique du systme
(tape II). En outre, le composant SystemView est rinitialis (tape III), c'est dire tous les liens
de communication entre les applications prcdemment autoriss sont supprims. Il est noter
que l'tat par dfaut de SystemView n'est rinitialise quaprs la mise jour de SystemPolicy et
quil conserv aprs chaque redmarrage.
Vers lapprivoisement des attaques dlvation de privilges sur Android Universit Laval -H2013
Rdig par Nina TCHALLA Scurit &mthodes formelles
10
Instanciation de la vue systme : reprsentation graphique
Nous allons dans cette partie un peu plus technique, prsenter la reprsentation orient graphe
du systme.
Pour reprsenter ltat du composant SystemView, la reprsentation base sur les graphes a t
choisi, o les sommets reprsentent les entits telles que les SandBoxs des applications, des
composants du systme, des fichiers tandis que les artes reprsentent la communication et les
liens d'accs entre eux. Par consquent, nous considrons le systme Android comme un graphe G
constitu d'un ensemble v(6)de sommets et un ensemble s(6) dartes directs. Une arte
e s(6) est une paire ordonne e = (|, j), o |, j v | j. Il existe quatre types de
graphe sommets A, S, F, I et reprsentant l'ensemble des SandBoxs des applications, des
composants du systme, des fichiers et des sockets Internet. Par ailleurs, lon dfinit les trois types
de artes savoir les appels ICC H, l'accs aux fichiers Ket les sockets/connexions Internet E. Les
appels ICC entre deux SandBoxs dapplication et les connexions Internet tablies sont reprsents
comme des artes bidirectionnelles dans les graphes.
Les arrtes
Les arrtes de M peuvent connecter les sommets reprsentant une SandBox d'application A et/ou
des composants du systme S:
e M: e = (| , j), |, j A S, | j.
Les arrtes de K ne peut connecter que des paires de sommets, o un sommet est un SandBox
d'application dans A et l'autre est un fichier dans F (paire ordonne reprsentant
lecture/criture):
e K: e = (| , j), (| A, j F) (| F, j A).
Les arrtes qui reprsentent les connexions Internet ne peuvent connecter que les paires de
sommets, o un sommet est un SandBox d'application et l'autre est un socket Internet :
e H: e = (| , j), | A , j I).
La figure suivante montre un aperu du graphe avec tous les types de sommets et d'artes dfinis.

Figure 4. Reprsentation graphique du systme
Vers lapprivoisement des attaques dlvation de privilges sur Android Universit Laval -H2013
Rdig par Nina TCHALLA Scurit &mthodes formelles
11
Les proprits des sommets
Chaque sommet V dans le graphe systme G se voit attribuer les proprits correspondantes:
un identifiant unique U (V) (cest--dire une UID pour un SandBox, un UID virtuel pour un
composant systme, un nom de chemin ou de fichier pour les fichiers et l'adresse IP et le
port pour les sockets Internet),
et un niveau de confiance T (V) = (true, false) o on distingue actuellement deux niveaux
de confiance: non fiable sont des applications tierces, tandis que de confiance sont les
applications par dfaut Android et les composants du systme.
En outre, les sommets fichiers et sockets Internet sont galement considrs comme de confiance.
C'est parce que les fichiers ou les sockets elles-mmes ne peuvent pas excuter une attaque
d'escalade de privilge, mais peut servir de moyen de communication pour des applications
malveillantes de la mme faon que les composants du systme considrs comme de confiance.
En outre, les SandBoxs d'application disposent de proprits supplmentaires, en particulier, les
noms des applications incluses dans un SandBox (par exemple, noms de paquets) N (A), la liste des
composants d'application pour chaque application C (A), et l'ensemble des autorisations valables P
(A) pour l'application A.
Les chemins
Un chemin L (u
1
, u
n
) = e
1
, e
2
, . , e
n-1
dans un graphe 0 entre les sommets :
1
et :
n
est une
squence darrtes e
1
= (u
1
, u
2
), e
2
= (u
2
, u
3
), ., e
n-1
= (u
n-1
, u
n
), o e
1
, e
2
, . , e
n-1

s , u
|
u
j
puur |, j 1 , 2 , . , n. En d'autres termes, un chemin est une squence acyclique
d'artes reliant les sommets. Nous dfinissons deux proprits du chemin:
une longueur de chemin, qui est dsign comme | L (u
1
, u
n
)| = n 1,
et un ensemble de donnes D(L) transmis par le chemin.
Reprsentation graphique de llvation de privilge
En utilisant toutes les informations et proprits tablies ci-dessus, on peut reprsenter
graphiquement une lvation de privilge. On dfinit des modles d'attaques dlvations de
privilges en spcifiant un ensemble d'autorisations critiques dans le systme. Par exemple,
obtenir des privilges permettant la fois d'accder Internet et l'information de localisation
peut tre dfini comme un modle d'attaque correspondant un traqueur demplacement. On
note les permissions critiques fixes par 2. Dans une attaque de vice , une application non
privilgi A J peut obtenir un ensemble critique de permissions Z en invoquant une
application privilgie B J, s'il existe un chemin de communication L (A, B). Une attaque
dlvation de privilge par les collusions dapplications A , B J peut se produire quand il ya
un lien de communication L (A, B) L (B , A) entre deux applications, et chaque srie de
privilges 3 (A)et 3 (B) ne correspond pas l'ensemble critique de privilges tandis quune
union des deux correspond, cest--dire :
2 3 (B) 2 3 (A) (2 (3 (A) 3 (B)))
Vers lapprivoisement des attaques dlvation de privilges sur Android Universit Laval -H2013
Rdig par Nina TCHALLA Scurit &mthodes formelles
12
IV. Politique de scurit
Pour contrer les diffrents modles dattaques, des profils de scurit sont dfinis pour chaque
modle. Aussi a-t-on les profils DefaultProfile, BasicProfile, AdvancedProfile et StrongProfile qui
correspondent respectivement aux modles ennemis WeakAdversary, BasicAdversary,
AdvancedAdversary et StrongAdversary.
DefaultProfile peut tre, par exemple, activ par dfaut, sous la forme de rgles de politique qui
aident se dfendre contre les attaques de vice connu. En outre, les rgles de politique
pourraient tre dfinies de telle sorte qu'elles n'entranent pas de faux positifs n'affectant pas
ainsi la convivialit. Ce profil peut tre mis jour, par exemple, par Google, sous forme de patchs
de scurit lors de la dcouverte de nouvelles attaques.
Les rgles de politique de scurit sont bases sur un langage inspir de VALIDE. VALIDE est un
langage d'assurance de scurit formel dvelopp pour les topologies d'infrastructure virtuelle. La
langue est trs convenable pour la solution propose car il est capable d'exprimer des oprations
sur les graphes, tels que le flux de l'information dans un modle graphique de la topologie sous-
jacente. Quand mapp sur notre graphique de reprsentation du systme (cf. section 4.3), il est
utilis pour exprimer les tats du systme qui dcrivent les attaques d'escalade de privilges.
VALIDE dcrit les proprits de sommets du graphe, mais est limit exprimer des proprits de
chemin. Pour les besoins du framework, il a t tendu pour spcifier les proprits de chemins,
comme la source de chemin, la destination du chemin, les donnes transmises sur le chemin, etc.
La figure ci-dessous illustre une rgle de politique pour prserver la confidentialit des appels
tlphoniques. Par exemple, nous avons dj expliqu le scnario d'attaque de Soundcomber dans
les types dattaques, qui vise la confidentialit des appels tlphoniques des utilisateurs. Cette
rgle dfinit donc un ensemble dautorisations indsirables qui permettrait des logiciels
malveillants denregistrer les appels ou de transfrer des donnes enregistres vers Internet.


Figure 5. Une rgle de scurit visant dfier les attaques de gestion malveillante dappels
tlphoniques

Vers lapprivoisement des attaques dlvation de privilges sur Android Universit Laval -H2013
Rdig par Nina TCHALLA Scurit &mthodes formelles
13
V. Evaluation de lefficacit et de la performance
Dans cette section, nous allons prsenter dans un premier temps une analyse heuristique
effectue sur les modes de communications des applications sur Android. Nous prsenterons enfin
les rsultats des tests sur l'efficacit et la performance de la solution propose.
Mthodologie des tests
La mthodologie de lvaluation a consist des tests manuels avec un groupe de 25 utilisateurs
de test. La tche des utilisateurs test consistait installer et utiliser fond les applications
fournies, pour dclencher autant que possible des caractristiques cibles des applications.
Communication des applications tierces
Concernant les communications bases sur les systmes de fichiers et les sockets, Les applications
testes non seulement ne partagent pas leurs donnes avec d'autres applications au niveau du
systme de fichiers, mais galement ne communiquent pas les uns avec les autres via les sockets
Unix. Par consquent, un vecteur d'attaque qui utilise des fichiers ou des sockets Unix comme
moyen de communication pourrait tre facilement identifie ce qui rend plus facile la prvention
dune telle une attaque. En outre, du moment o les applications lgitimes sont beaucoup moins
susceptibles de communiquer de cette faon, le taux de communications ni tort devrait tre
faible.
Pour ce qui est des communications bases sur les ICC, lanalyse montre que les applications
fonctionnent habituellement de faon autonome et nont pas dinterdpendances fonctionnelles
avec d'autres applications. Les exceptions sont certaines applications personnalises qui
dmarrent d'autres applications et les applications avec la fonctionnalit "partager" qui reoivent
des donnes partir d'autres applications de partage (par exemple, Facebook, Twitter, etc.). La
solution rpond avec prcision ce modle de communication, car, il met tout dabord en uvre
une politique trs fine dans les composants du systme, et ensuite la communication directe entre
les applications.
Efficacit
Pour valuer lefficacit du framework, lemphase a t mis sur le taux de dtection des attaques
prcises dans la politique du systme (par exemple, le taux de faux ngatifs) et le taux de
communications entre les applications ni tort (par exemple, taux de faux positifs). Une solution
idale fournirait comme rsultat un taux de faux positifs et un taux de faux ngatifs tous les deux
nuls. La solution actuelle applique une sur-approximation des liaisons de communication. Cela
signifie qu'on suppose une relation entre les canaux de communication mme sil nen existe pas,
par exemple, il n'a pas de faux ngatifs, mais tend provoquer des faux positifs.
Taux de dtection d'attaque.
Pour valuer le taux de dtection des attaques dlvation de privilges, des exemples
d'applications qui implmentent les attaques rcurrentes dcrites dans les sections prcdentes
ont t dvelopps et une stratgie systme a t dploye ; elle contient des rgles visant ces
attaques (voir tableau 3 en annexe B).
Vers lapprivoisement des attaques dlvation de privilges sur Android Universit Laval -H2013
Rdig par Nina TCHALLA Scurit &mthodes formelles
14
Le framework propos a dtect avec succs toutes les attaques mentionnes ci-dessus au niveau
des ICC, des sockets, et au niveau du systme de fichiers, y compris tous les scnarios d'attaque de
Soundcomber lance par canaux cachs dans les composants du systme Android.
Taux de communication ni tort
Laction mene lors de cette valuation est la mesure de limpact du framework de scurit sur
lutilisabilit des applications tierces. Pendant cet essai, en plus des rgles de la politique du test
de dtection des attaques, les concepteurs ont dploy des rgles gnriques pour empcher la
fuite d'informations sensibles comme la localisation de l'appareil, contacts, SMS ou via Internet. En
outre, il a t une rgle singulire qui permet aux applications de lancer d'autres applications avec
une intention si et seulement si l'intention ne contient pas de donnes ou de l'information
supplmentaire (voir la rgle 12 de l'Annexe B). Les rsultats des tests n'ont pas montr de faux
positifs. Cest d'une part contre-intuitif, car les rgles de la politique de lAdvancedProfile et le
StrongProfile sont assez gnriques et sont rvlatrices d'un taux lev de faux positifs. D'autre
part, ce rsultat confirme les observations et conclusions sur les modes de communication entre
des applications tierces sur Android.
Performance
La solution propose n'impose qu'une surcharge d'excution ngligeable, pas perceptible par
l'utilisateur. Les tableaux 1 et 2 prsentent les rsultats de lvaluation. En particulier, comme
montre le tableau, la latence de lexcution des appels systme est faible compte tenu du rapport
de mise en cache des dcisions par rapport celle qui ne le sont pas encore. Seule la tte sur les
messages d'intention ne peut pas tre optimise par la mise en cache.


Figure 6. Table 1 : Rsultats du chronomtrage des ICC Table2 : Rsultats du chronomtrage des
composants systme
Sur l'accs en lecture aux fournisseurs de contenu systme, le filtrage des valeurs contradictoires
avec la politique du systme impose un surcot d'environ 48%. Sur l'accs en lecture au
composant SystemServices, la surcharge est simplement l'ordre de 2,4% en moyenne. Cet cart
s'explique par le fait que, sur l'accs en lecture aux fournisseurs de contenus, gnralement
plusieurs paires lecteur-graveur doivent tre vrifis, tandis que l'accs aux services de systme
implique une seule paire de lecture-criture.
Vers lapprivoisement des attaques dlvation de privilges sur Android Universit Laval -H2013
Rdig par Nina TCHALLA Scurit &mthodes formelles
15

Conclusion
Les principaux problmes abords lors de lanalyse de cet article sons les attaques de vice et
les attaques de collusion sur Android. Les auteurs de ce document ont donc propos une solution
qui impliquait la conception et la mise en uvre d'un framework pratique pour la scurit
dAndroid ; ce framework est charg de surveiller les canaux de communication des applications
dans la couche middleware d'Android et dans le noyau Linux sous-jacent ( savoir, IPC, systme de
fichiers, domaine Unix et socket Internet) et de veiller ce qu'ils respectent la politique de scurit
du systme.
Nous pouvons dire, daprs cet article et toutes les analyses qui y ont t menes que la
conception propose rpond avec prcision aux observations, car elle met en uvre une politique
de scurit trs fine dans les composants du systme, qui sont les principaux moyens pour les
applications de partager des donnes. Principalement inspir par QUIRE, les rsultats de
lvaluation de la politique montrent quil est efficace et utilisable. Il peut empcher publi les
attaques dlvations escalade de privilge rcemment publies, y compris les attaques
sophistiques comme Soundcomber lanc par des canaux cachs dans les composants du systme
Android.
Pour lavenir, il est prvu des tests utilisateurs tendues de la politique de scurit en utilisant un
grand nombre d'applications partir de l'Android Market. Enfin, il un projet dintgration de
SELinux dans la politique de scurit est envisag.