Cours MIT "Sécurité des systèmes informatiques". Conférence 20: Sécurité des téléphones portables, partie 2

Institut de technologie du Massachusetts. Cours magistral # 6.858. "Sécurité des systèmes informatiques." Nikolai Zeldovich, James Mickens. 2014 année

Computer Systems Security est un cours sur le développement et la mise en œuvre de systèmes informatiques sécurisés. Les conférences couvrent les modèles de menace, les attaques qui compromettent la sécurité et les techniques de sécurité basées sur des travaux scientifiques récents. Les sujets incluent la sécurité du système d'exploitation (OS), les fonctionnalités, la gestion du flux d'informations, la sécurité des langues, les protocoles réseau, la sécurité matérielle et la sécurité des applications Web.

Cours 1: «Introduction: modèles de menace» Partie 1 / Partie 2 / Partie 3
Conférence 2: «Contrôle des attaques de pirates» Partie 1 / Partie 2 / Partie 3
Conférence 3: «Débordements de tampon: exploits et protection» Partie 1 / Partie 2 / Partie 3
Conférence 4: «Séparation des privilèges» Partie 1 / Partie 2 / Partie 3
Conférence 5: «D'où viennent les systèmes de sécurité?» Partie 1 / Partie 2
Conférence 6: «Opportunités» Partie 1 / Partie 2 / Partie 3
Conférence 7: «Native Client Sandbox» Partie 1 / Partie 2 / Partie 3
Conférence 8: «Modèle de sécurité réseau» Partie 1 / Partie 2 / Partie 3
Conférence 9: «Sécurité des applications Web», partie 1 / partie 2 / partie 3
Conférence 10: «Exécution symbolique» Partie 1 / Partie 2 / Partie 3
Conférence 11: «Ur / Web Programming Language» Partie 1 / Partie 2 / Partie 3
Conférence 12: Sécurité du réseau, partie 1 / partie 2 / partie 3
Conférence 13: «Protocoles réseau», partie 1 / partie 2 / partie 3
Conférence 14: «SSL et HTTPS» Partie 1 / Partie 2 / Partie 3
Conférence 15: «Logiciel médical» Partie 1 / Partie 2 / Partie 3
Conférence 16: «Side Channel Attacks» Partie 1 / Partie 2 / Partie 3
Conférence 17: «Authentification des utilisateurs», partie 1 / partie 2 / partie 3
Conférence 18: «Navigation privée sur Internet» Partie 1 / Partie 2 / Partie 3
Conférence 19: «Réseaux anonymes» Partie 1 / Partie 2 / Partie 3
Conférence 20: «Sécurité des téléphones portables» Partie 1 / Partie 2 / Partie 3

Avant de commencer un examen détaillé du système, essayons de découvrir une chose intéressante: pourquoi ces types ont-ils développé une conception modulaire complètement nouvelle pour les applications Android? Il y a des applications bureautiques, il y a des applications web, pourquoi avaient-ils besoin d'inventer une toute nouvelle façon d'écrire des logiciels? En effet, dans un sens, cela prête à confusion pour le développeur. Parce que, disons, je suis habitué à écrire mon petit programme en C avec la fonction principale, et maintenant je le regarde et je dis: «qu'est-ce qui se passe? Que vais-je faire avec tout ça? Je dois définir quatre types de composants et envoyer des intentions, au lieu d'utiliser des structures C et d'écrire du code en lignes régulières? »



Quels sont donc les avantages et les inconvénients des modèles d'application existants? Nous avons des applications de bureau et Internet, pourquoi avons-nous besoin d'un troisième type d'application?
Étudiant: mais le modèle a complètement changé, non? Je pense que vous ne devriez pas faire autant confiance aux développeurs d'applications bureautiques qu'aux développeurs d'applications pour appareils mobiles. De plus, vous avez des utilisateurs plus expérimentés par rapport au nombre d'utilisateurs expérimentés d'applications informatiques, et ils veulent utiliser tout un tas d'applications isolées les unes des autres.

Professeur: très probablement. Alors, pensez-vous que dans le cas des applications de bureau, nous ne devrions pas trop faire confiance à leurs développeurs?

Étudiant: bien sûr, car il y a toujours un fils ou un cousin plus expérimenté qui vous aidera à résoudre des problèmes avec les programmes informatiques, mais les choses sont différentes avec le téléphone.

Professeur: C’est bien sûr cool que les téléphones n’aient pas besoin d’un cousin pour s’occuper d’eux. Mais d'un point de vue de la sécurité, les programmes informatiques ont une propriété caractéristique - l'installation d'une nouvelle application sur un ordinateur peut être un processus assez long. Ce n'est peut-être pas tout à fait vrai, car vous pouvez toujours cliquer sur le fichier exécutable et démarrer l'installation, mais je ne pense pas que les gens installent régulièrement des applications de bureau. Après tout, en règle générale, vous disposez d'un ensemble fixe de logiciels que vous exécutez.

En ce sens, une caractéristique distinctive des applications Web est leur lancement facile. Vous allez simplement sur le site, et vous n'avez rien d'autre à faire que de cliquer sur le lien, et maintenant vous êtes déjà sur un nouveau site sous le contrôle d'une nouvelle application. C'est donc une assez bonne propriété d'une application Web.



Une mauvaise caractéristique des applications informatiques est le manque d'isolement des applications. C'est peut-être en quelque sorte dû au fait que lorsque vous installez une telle application, vous faites entièrement confiance à tout ce qui se trouve sur votre ordinateur. En fait, il n'y a pas d'isolement entre l'application que vous installez sur votre ordinateur portable et tout autre programme ou donnée qui existe déjà, alors que dans le cas de l'application Web, il y a une certaine isolation raisonnable. Tant que vous faites confiance à la même politique d'origine, vous êtes en sécurité. Par conséquent, il est suffisamment sûr d'aller sur un site Web arbitraire et de commencer à utiliser son application. Si cette application ne tire pas parti des vulnérabilités de votre navigateur, elle n'interférera pas avec le fonctionnement des sites ouverts dans les autres onglets du navigateur.



Les applications Web semblent toujours mieux placées, car elles sont faciles à utiliser et isolées. Pourquoi ces gars n'utilisent-ils pas les applications Web Android?

Etudiant: les applications web semblent contenir un système d'exploitation, c'est-à-dire par exemple un Firefox OS, qui est essentiellement un OS Internet mobile.

Professeur: bien sûr. Vous prétendez que ces gars ont vraiment tort. Ils n'étaient pas censés créer un nouveau système d'exploitation Android, mais simplement créer un navigateur Web géant pour votre téléphone.

Étudiant: au moins Mozilla a montré que c'était possible.

Professeur: eh bien, c'est assez juste. À tout le moins, il est plus sage de suivre la voie de la création d'applications Web que les systèmes de bureau, du moins pour le téléphone.

Étudiant: étant donné que vous passez un appel téléphonique à partir d'une application Web, vous devez créer une toute nouvelle API pour communiquer l'interface de l'application Web avec le téléphone.

Professeur: bien sûr. Ainsi, les applications Web ont une limitation qui peut être corrigée: l'absence d'une API pour certains appareils mobiles. Mais il y a moins de telles applications. Par exemple, pour une caméra ou un navigateur GPS, ils ajoutent lentement, mais toujours l'interface appropriée aux applications Web. Mais là, dans les applications Web, il n'y a probablement pas encore d'API pour passer des appels, envoyer des SMS et autres.

Un autre inconvénient des applications Web est l'impossibilité d'établir un accès limité à d'autres applications. Nous avons parlé des intentions implicites dans Android, où vous pourriez simplement dire: «Je veux voir cette image JPEG, mais qui sait quelle application l'ouvrira? Soit je veux afficher ce fichier PDF, soit partager cette photo avec mon ami que je viens de prendre avec mon appareil photo, mais je ne sais pas quelle application de messagerie électronique sera utilisée. " Alors demandons simplement au moniteur de liens de me trouver un programme de messagerie qui va envoyer cette photo. Sur un appareil Android, cela est facile à faire, mais dans le cas des applications Web, cela posera de grandes difficultés, car chaque interaction doit être liée à une URL spécifique.



Donc, si vous ne savez pas quel lecteur PDF quelqu'un utilise, vous ne saurez pas quelle URL vous pouvez utiliser pour afficher votre fichier.

Étudiant: peut-être un inconvénient des applications Web est que JavaScript est très difficile à lire?

Professeur: oui, c'est un autre inconvénient, c'est qu'ils sont tous écrits en JavaScript. Par conséquent, cela peut ne pas être très bon en termes de performances, il peut être difficile de comprendre ce que fait le programme, il peut être difficile de compiler efficacement, etc.

Revenons aux programmes informatiques. Une fonctionnalité utile des applications de bureau est la possibilité de partager des fichiers. Tous vos fichiers sont disponibles dans chaque application car vous les partagez. Ainsi, vous avez un accès facile à toutes les données disponibles sur l'ordinateur.



Ce qui est un peu difficile à mettre en œuvre dans Android est facile à faire dans les applications informatiques. Dans le cas des OS de bureau, si je veux compiler un logiciel, je vais exécuter MAKE, exécuter GCC et, éventuellement, d'autres programmes, et ils fonctionneront tous sur le même code source C dans le même répertoire. C'est beaucoup plus difficile à faire dans Android, où les données sont associées à l'application principale, qui est stockée par le fournisseur de contenu. Vous devez donc le bricoler, en utilisant d'abord le référentiel de code source, puis en installant le compilateur C, le programme MAKE, l'assembleur et plus encore. Il est beaucoup plus difficile de les faire travailler ensemble.

Cela peut être fait en contournant certaines des limites d'Android, mais en tout cas plus compliqué que sur les systèmes de bureau.

Étudiant: Je pense que l'optimisation des applications Web est assez difficile, elles sont limitées par l'utilisation de la RAM et de la puissance de traitement.

Professeur: oui, les principes d'optimisation des applications Web et des applications de bureau sont différents. Je crois que l'inconvénient des applications Web, au moins au moment où elles concevaient Android, était que le lancement de l'application Web hors ligne était très difficile. Si votre téléphone capte un signal réseau faible, certaines applications seront difficiles à lancer, surtout si certaines de leurs pièces sont tombées du cache. Cependant, je pense que, comme vous l'avez remarqué, les applications Web, bien que lentement, «rattrapent» Android en éliminant les restrictions actuelles. Il est donc tout à fait possible que les applications Web servent de modèle raisonnable pour lancer une nouvelle plate-forme d'exploitation téléphonique. Mais il y a cinq ans, ils n'étaient pas assez bons pour cela.

Mais même en dépit des lacunes existantes, il sera désormais beaucoup plus facile de «pousser» les applications Web dans le créneau occupé par Android, plutôt que de commencer à développer un nouvel OS mobile à partir de zéro. Par conséquent, je pense que nous pouvons encore parler des succès de ce qu'Android a fait, même si peut-être aujourd'hui vous préféreriez ne pas le faire de cette façon.
Je pense qu'en termes d'isolement, la sécurité du système Android est beaucoup plus élevée. Comme je l'ai mentionné, Android s'appuie sur le noyau Linux pour isoler les applications les unes des autres. La plate-forme Android définit en fait les ID utilisateur, donc cette App1 aura l'UID 1001, l'App 2 aura l'UID 1002, et le moniteur de liens, qui a généralement les privilèges root, aura l'UID 0. Le noyau Linux est donc en grande partie responsable de Séparation des applications les unes des autres.



Fondamentalement, l'interaction entre les identifiants des utilisateurs se produit par des intentions d'intention. Il y a beaucoup plus de nuances sur la façon dont le noyau Linux contrôle les applications en utilisant l'UID, nous en parlerons un peu plus tard.

Une question intéressante: pourquoi ces gars-là ont choisi Java? Quel est le rôle de Java dans Android? Pourquoi est-il nécessaire? Si nous écrivons toutes les applications en C au lieu de Java, ou, par exemple, Assembleur, quelque chose peut-il casser?

Étudiant: si vous avez des vulnérabilités, l'utilisation de ces langages peut entraîner une distorsion des indicateurs importants pour le système.

Professeur: oui, cela peut arriver, par exemple, un débordement de tampon peut se produire dans l'application. Quoi d'autre?

Étudiant: une confusion avec les autorisations peut se produire.

Professeur: avec quelles autorisations?

Étudiant: avec comme la latence, la latence.

Professeur: regardons cela de plus près. Ainsi, comme nous l'avons dit, le moniteur de liens vérifie les balises pour nous et stocke réellement dans le système Android une liste de toutes les applications installées ainsi que des balises correspondant à toutes ces applications. Vous ne voudrez donc probablement pas que le moniteur de liens fasse des erreurs, quelle que soit la langue dans laquelle il est écrit. Donc, avoir un moniteur de liens écrit dans un langage de type sécurisé est une bonne solution. J'aime Java parce que c'est un langage sûr avec de bonnes fonctionnalités. Mais même si l'application était écrite en C et que des débordements de tampon s'y produisaient, elle ne pourrait toujours pas endommager les étiquettes du moniteur de liens. Ce ne serait donc pas un gros problème.

Étudiant: peut - être existe-t-il une sorte de système qui peut endommager le code écrit en C?

Professeur: oui, donc, en principe, il serait bien d'éviter les applications qui parlent directement au noyau Linux. Sous Android, ce n'est pas le cas. Les applications Android peuvent effectuer des appels système arbitraires si elles le souhaitent. En fait, pour des raisons de performances, les applications ne peuvent pas affecter des composants arbitraires écrits en C ou Assembleur, c'est pourquoi certains jeux "parlent" en Java.

Étudiant: Je pense que d'une certaine manière, c'est l'occasion d'utiliser tout le matériel écrit pour Java, c'est-à-dire que les créateurs d'Android voulaient simplifier la création d'applications pour les développeurs. Et l'un des moyens les plus simples de le faire est de permettre de profiter des volumineuses bibliothèques Java.

Professeur: très probablement. Je pense que l'une des principales raisons d'utiliser Java est la convivialité. Ils étaient probablement plus préoccupés par la programmation et la facilité de développement, car Java a peu à voir avec la sécurité.

Une autre chose qui a sa place ici, contrairement à iPnone. Le système d'exploitation iPhone a également une facilité de développement, mais utilise C, et si vous essayez, vous pouvez provoquer un débordement de tampon. De plus, il existe une spécificité pour un équipement particulier, donc tous peuvent ne pas avoir les mêmes bibliothèques. Je pense que la principale raison pour laquelle les développeurs Android ont choisi Java est qu'ils ne connaissaient pas initialement les caractéristiques des appareils sur lesquels ce système d'exploitation fonctionnera. Par exemple, les créateurs de l'iPhone savaient avec certitude qu'ils auront un processeur ARM dans leur téléphone, ils ont donc pré-compilé le logiciel avec ce modèle particulier. Et cette approche est plus efficace, car la consommation de la batterie est d'une grande importance pour le téléphone.



Le fait que les gars d'Android utilisent Java est probablement moins efficace en termes d'économie d'énergie ou de performances du processeur, car il est lié au JRE et ainsi de suite. Mais il y a aussi l'avantage de porter le système d'exploitation sur des appareils avec des architectures différentes. Par conséquent, si vous possédez des téléphones dotés de processeurs MIPS, ARM ou x86, l'application Java peut être exécutée sur les trois appareils. Les développeurs Android souhaitaient que leur plateforme soit utilisée sur tout type d'équipement ou de téléphone. C'est donc probablement la principale raison pour laquelle ils ont sacrifié la sécurité pour utiliser Java.

Il s'avère que l'environnement d'exécution Java n'offre aucun avantage de sécurité spécial pour les applications, c'est juste une chose pratique pour les développeurs et les utilisateurs. Mais du point de vue de l'isolement, tout dépend essentiellement du noyau et du moniteur de liens qui contrôle le fonctionnement des applications.

Étudiant: La facilité de développement ne conduit-elle pas à une certaine sécurité des applications? En effet, lors de l'écriture d'un moniteur de références C, il existe de nombreuses autres façons de faire des erreurs.

Professeur: oui, vous avez absolument raison! En fait, je n'aurais pas dû dire que la facilité de développement n'a rien à voir avec la sécurité. C'est complètement stupide car vous voulez le faire aussi facilement que d'écrire le bon code. Donc, dans un sens, un système pour lequel vous pouvez facilement écrire seul le code correct offre plus de sécurité. Dans un sens, vous avez raison de supposer que les développeurs Android voulaient éviter les erreurs lors de l'écriture de code, donc vous ne vouliez pas l'écrire dans le langage complexe C. Et je ne sais pas pourquoi Apple a choisi C comme langage de programmation lors du développement de son système d'exploitation.

Parce qu'un tel choix crée un problème de dépassement de tampon dans l'application, et si cette application est d'une grande importance, alors elle est potentiellement vulnérable. Pas par rapport à la compromission d'autres applications, mais vous ne voulez toujours pas que votre application bancaire soit écrite en C.



Étudiant: Link Monitor écrit en Java ou C?

Professeur: Sous Android, le moniteur de liens est principalement écrit en Java. Cependant, il contient des «crochets» pour communiquer avec des interfaces et des applications externes en utilisant du code natif. Mais la majeure partie de la logique est écrite en Java. Il s'agit donc en fait d'un plan assez sûr.

Essayons maintenant de découvrir à quoi servent les UID d'application, sauf pour séparer les applications les unes des autres en termes de processus qu'elles lancent. La principale raison de l'utilisation de l'UID est de créer la possibilité de partager l'accès aux ressources partagées et d'échanger des données dans le système.

Nous avons déjà vu un mécanisme pour cela - l'envoi d'intentions au moniteur de liaison. Mais sur Android, il y a des tonnes de choses qui ne sont pas faites par le biais du moniteur de liens. Probablement, tout n'est pas envoyé via Intent pour des raisons de performances. Vous ne souhaitez pas appeler le moniteur de liaison pour chaque opération que vous effectuez sur le système, il s'agit tout d'abord de l'accès à Internet. Si vous souhaitez accéder à Internet dans un appareil exécutant Android, ouvrez simplement le socket, comme dans toute application Linux standard. Une application peut simplement demander au noyau: «J'ai besoin d'un socket parce que je veux me connecter à cette machine», c'est ainsi que l'on accède à Internet.

Ensuite, l'accès aux supports amovibles doit être noté. SD-, . , , , , , . , . , , Android . , , GPS-, .



«» Android, Linux, /dev/camera. Linux, , , . , - , , Java. C Assembler, Linux, . Java , Java-.

: , , - , ?

: , ! , . ? , №2, ID . Android UID GID , . , . , , , - «android.permission.internet», , .



, . , , , . — Linux Android. , - , - , , Linux. Android GID 3003, . , , . , - . Android - , . , GID UID .

SD-. GID, SD-, , . , . , SD- GID SD-.
, , Android.



, , , . , SQL -, , . — UID , , .

, , , GPS, . GID, . , , dev/camera - GID, , , GID .

, , №2, , UID GID , - .

, SD-? , SD-? , SD- , , . ?

: , , , , .

: . , Android , . , SD- . , , SD- . , Android , , , FAT, - . , , - .

: , ?

: , . , , . , , , , . , .



— , , ? , , DIALPERM, INTERNET, FRIENDVIEW?

: , , ?

: , , , . , , . , . Android , iOS, , iPhone , , , SMS-, JPEG . .

– , , . . , Android , , . , - «», , , , , OK. , , .

, , , Android , — , . , , , . Android, 4.3, , , . , . , , , , . , , API, , .

55:10

MIT « ». 20: « », 3


.

, . ? ? , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps , .

Dell R730xd 2 ? 2 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! . c Dell R730xd 5-2650 v4 9000 ?