Cours MIT "Sécurité des systèmes informatiques". Conférence 21: Suivi des données, 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
Conférence 21: «Suivi des données» Partie 1 / Partie 2 / Partie 3

Etudiant: pourquoi est-il tout simplement impossible de scanner le code sans le vérifier manuellement?

Professeur: en pratique, c'est ce qui se passe. Les développeurs savent que chaque fois que l'interpréteur effectue ce type de travail, lors du retour de la valeur de retour, un code spécial est utilisé qui attribue automatiquement la valeur système infectée à system.arraycopy (), qui doit lui être associée.

Étudiant: oui, mais quelle est alors la partie manuelle du travail?

Professeur: la partie manuelle est principalement de savoir quelle devrait être la politique d'exécution de l'audit. En d'autres termes, si vous regardez simplement TaintDroid standard ou Android standard, ils feront quelque chose pour vous, mais ils ne pourront pas attribuer automatiquement Taint de la bonne manière. Donc, quelqu'un doit attribuer manuellement une stratégie de suivi.



Il ne semble pas que ce sera un gros problème dans la pratique. Mais si le nombre d'applications qui utilisent des méthodes orientées machine a régulièrement augmenté, nous pouvons avoir de petits problèmes.

Les messages IPC constituent un autre type de données dont il faut s'inquiéter en termes d'attribution d'une infection. Les messages IPC sont essentiellement traités comme des tableaux. Par conséquent, chacun de ces messages sera associé à une seule souillure commune, qui est l'union des infections de toutes ses parties constituantes.

Cela contribue aux performances du système car nous n'avons besoin de stocker qu'une seule balise taint pour chacun de ces messages. Dans un cas extrême, un degré d'infection sera simplement réévalué, mais il n'entraînera jamais une diminution de la sécurité. La pire chose qui puisse arriver en même temps est que le réseau n'obtiendra pas de données qui pourraient y arriver sans conséquences dangereuses pour la confidentialité.

Ainsi, lorsque vous créez un message IPC, il reçoit la souillure combinée. Lorsque vous lisez ce que vous avez reçu dans ce message, les données extraites sont infectées par le message lui-même, ce qui est logique. C'est ainsi que les messages IPC sont traités.

Il convient également de s'inquiéter de la façon dont le fichier est traité. Par conséquent, chaque fichier reçoit une balise corrompue, et cette balise est stockée avec le fichier dans ses métadonnées sur un support de stockage stable, tel qu'une carte mémoire SD. Ici, la même approche conservatrice de l'infection a lieu que dans les cas précédents. L'idée principale est que l'application accède à certaines données confidentielles, par exemple l'emplacement GPS, et va probablement écrire ces données dans un fichier, donc TaintDroid met à jour la balise taint de ce fichier avec le drapeau GPS, après quoi l'application se ferme. Plus tard, une autre application qui lit ce fichier peut être incluse.



Lorsqu'il entre dans la machine virtuelle, dans l'application, TaintDroid voit qu'il a ce drapeau, et donc toutes les données extraites lors de la lecture de ce fichier auront également ce drapeau GPS. Je pense que c'est assez simple.

Alors, quelles choses pouvons-nous infecter du point de vue Java? Il existe essentiellement cinq types d'objets Java qui ont besoin de drapeaux corrompus. Premièrement, ce sont des variables locales Variables locales qui sont utilisées dans la méthode. En revenant aux exemples précédents, nous pouvons supposer que char c est une telle variable.

Par conséquent, nous devons attribuer des drapeaux à ces éléments. Le deuxième type correspond aux arguments de la méthode Arguments de la méthode; ils doivent également avoir des indicateurs d'infection. Ces deux choses vivent sur la pile, donc TaintDroid doit garder une trace de l'objectif des drapeaux et bien plus encore pour ces types d'objets.
Nous devons également affecter des indicateurs aux champs d'instance des champs d'instance d'objet. Imaginez qu'il y ait un certain objet C, c'est un cercle, et je veux connaître son rayon. Ainsi, nous avons le champ c.radius, et nous devons associer les informations d'infection pour chacun de ces champs: avec et rayon.
Le quatrième type d'objet Java est les champs de classe statiques des champs de classe statiques, qui nécessitent également des informations erronées. Cela peut être quelque chose comme circle.property, c'est-à-dire une description des propriétés du cercle pour lesquelles nous attribuons des informations à corrompre.

Le cinquième type est les tableaux de tableaux, dont nous avons parlé plus tôt, et nous attribuons un élément commun d'informations d'infection pour l'ensemble du tableau.

L'idée de base de l'implémentation de drapeaux taint pour ces types d'objets Java est d'essayer de stocker des drapeaux taint pour une variable à côté de la variable elle-même.



Disons que nous avons une variable entière et que nous voulons y placer une sorte de pollution polluante. Nous voulons essayer de garder cet état aussi proche que possible de la variable, peut-être pour des raisons d'assurer un fonctionnement efficace du cache au niveau du processeur. Si nous restons très éloignés de cette variable, cela pourrait causer des problèmes, car après que l'interprète aura examiné la valeur de la mémoire pour cette variable Java réelle, il voudra se familiariser avec les informations sur son infection le plus rapidement possible.

Si nous regardons l'opération move-op, nous remarquons qu'à ces endroits du code, dst et src, lorsque l'interpréteur prend en compte les valeurs, il prend également en compte les infections parasites correspondantes.

Ainsi, en plaçant ces éléments le plus près possible les uns des autres, vous essayez d'assurer une utilisation plus efficace du cache. C'est assez simple. Si vous regardez ce que les développeurs font pour les arguments des méthodes et des variables locales qui vivent sur la pile, vous pouvez voir qu'ils mettent essentiellement en évidence les drapeaux taint à côté de l'emplacement des variables.

Supposons que nous ayons une chose préférée à propos de nos conférences, un diagramme de pile que vous détesterez probablement bientôt pour une mention fréquente. Laissez la variable locale 0 se trouver dans notre pile, puis TaintDroid stockera en mémoire une balise sur l'infection de cette variable juste en dessous. Si vous avez ensuite une autre variable, sa balise sera également située directement en dessous, et ainsi de suite. C'est assez simple. Toutes ces choses seront situées sur la même ligne de cache, ce qui rendra l'accès à la mémoire moins cher.



Étudiant: Je me demande comment vous pouvez avoir un indicateur pour un tableau entier et différents indicateurs pour chaque propriété d'un objet. Que faire si l'une des méthodes de l'objet peut accéder aux données stockées dans ses propriétés? Ce serait ... vous savez ce que je veux dire?

Professeur: Demandez-vous pourquoi vous appliquez une telle politique?

Étudiant: oui, sur la raison de l'utilisation d'une telle politique.

Professeur: Je pense que cela est fait pour garantir l'efficacité de la mise en œuvre. Il existe probablement d'autres règles - par exemple, elles ne signalent pas la longueur du tableau de données, car une fuite d'informations est possible, elles n'étendent donc pas l'infection à cet indicateur. Je pense donc que certaines décisions sont prises simplement pour des raisons d'efficacité. En principe, il n'y a rien qui gênerait en donnant accès à chaque élément du tableau pour indiquer que la chose à gauche ne reçoit de souillure que de la part d'éléments spécifiques.

Cependant, il n'est pas clair si cela sera correct, car, apparemment, si vous mettez quelque chose dans le tableau, alors cette chose devrait savoir quelque chose sur ce tableau. Par conséquent, je pense que les développeurs utilisent une combinaison des deux politiques. Étant trop conservateur, vous ne devez pas autoriser la fuite de données que vous souhaitez protéger, mais en même temps, pour avoir accès au tableau, vous devez en savoir quelque chose. Et lorsque vous avez besoin d'apprendre quelque chose, cela signifie généralement que vous utilisez la souillure.

C'est donc le schéma de base qu'ils utilisent pour stocker toutes ces informations côte à côte. On peut imaginer que la même chose se fait pour les champs de classe et pour les champs d'objet. Lorsque vous déclarez une classe, vous avez de la mémoire d'emplacement pour une variable particulière, et juste à côté de cet emplacement se trouvent des informations impures pour cette variable. Je pense donc que tout cela est assez raisonnable.

C'est le principe de TaintDroid. Lorsque le système est initialisé ou à d'autres moments pendant son fonctionnement, TaintDroid examine toutes les sources d'informations potentiellement infectées et attribue un indicateur à chacune de ces choses - capteur GPS, appareil photo, etc. Au fur et à mesure que le programme s'exécute, il extrait des informations confidentielles de ces sources, après quoi l'interprète examinera tous les types de fonctions conformément au tableau donné dans l'article pour savoir comment propager une infection infectieuse à travers le système.

La chose la plus intéressante se produit lorsque les données tentent de pénétrer le système. TaintDroid peut contrôler les interfaces réseau et voir tout ce qui tente de les traverser. Il recherche les balises viciées et si les données qui tentent de pénétrer le réseau ont un ou plusieurs de ces drapeaux, il leur sera interdit d'utiliser le réseau. Ce qui se passe en ce moment dépend en fait de l'application.



Par exemple, TaintDroid peut montrer à l'utilisateur un avertissement disant que quelqu'un essaie d'envoyer des données sur son emplacement sur le côté. Il est possible que TaintDroid contienne des politiques intégrées qui permettront à l'application d'accéder au réseau, mais en même temps, réinitialisera toutes les données sensibles qu'elle tentera de transférer, etc. Dans l'article, ce mécanisme n'est pas décrit de manière suffisamment détaillée, car les auteurs étaient principalement préoccupés par la question des «fuites» de données dans le réseau.

Une section de l'article intitulée «Évaluation» examine certaines des choses trouvées dans le processus d'étude du système. Ainsi, les auteurs de l'article ont constaté que les applications Android essaient d'extraire des données de manière invisible pour l'utilisateur. Supposons qu'ils essaient d'utiliser votre emplacement pour faire de la publicité, ils enverront votre numéro à un serveur distant, etc. Il est important de noter que ces applications, en règle générale, ne «cassent» pas le modèle de sécurité Android dans le sens où l'utilisateur doit leur permettre d'accéder au réseau ou leur permettre d'utiliser la liste de contacts. Cependant, les applications ne prévoient pas dans l'accord de licence du CLUF qu'elles ont l'intention d'envoyer un numéro de téléphone à un serveur Silk Road 8 ou quelque chose du genre. En fait, il s'agit d'une fraude et d'induire les utilisateurs en erreur quant aux véritables intentions de l'application, car s'ils voyaient ces exigences du CLUF et savaient de quoi ils étaient chargés, ils pourraient penser à installer une telle application sur leur smartphone ou non.

Étudiant: on peut supposer que même si ces conditions étaient incluses dans l'accord de licence, cela ne fonctionnerait pas, car les gens ne lisent généralement pas le CLUF.

Professeur: c'est une hypothèse très raisonnable, car même les informaticiens ne vérifient pas toujours l'accord de licence. Cependant, une telle honnêteté à l'EULA serait toujours bénéfique, car il y a des gens qui lisent vraiment l'accord de licence. Mais vous avez tout à fait raison de supposer que les utilisateurs ne liront pas un tas de pages écrites en petits caractères, ils cliquent simplement sur «Accepter» et installent l'application.

Donc, je pense que les règles pour transmettre des informations à travers le système sont assez simples, comme nous l'avons déjà dit, la souillure se déplace simplement du côté droit vers le côté gauche. Cependant, ces règles de circulation des informations peuvent parfois avoir des résultats quelque peu contradictoires.
Imaginez qu'une application implémente sa propre classe de listes chaînées. Nous avons une classe simple appelée ListNode, elle aura un champ d'objet pour les données d'objet et un prochain objet ListNode qui représente la liste suivante.

Supposons que l'application affecte des données infectées au champ de données d'objet - informations confidentielles reçues d'un capteur GPS ou autre chose. La question est, lorsque nous calculons la longueur de cette liste, doit-elle être infectée? Vous serez étonné que la réponse à la question soit «non», ce qui s'explique par la façon dont TaintDroid et certains de ces systèmes déterminent le flux d'informations. Voyons ce que cela signifie d'ajouter un nœud à une liste chaînée.

L'ajout d'un nœud consiste en 3 étapes. Ainsi, la première chose que vous faites est de sélectionner un nouveau nœud de liste qui contient les données que vous souhaitez ajouter - Alloc ListNode. La deuxième étape consiste à affecter un champ de données à ce nouveau nœud. Et la troisième chose que vous faites est d'utiliser une sorte de patch pour ListNode à côté de fusionner les nœuds dans une liste - c'est le pointeur ptr «suivant».



Fait intéressant, la troisième étape n'est pas du tout liée au champ de données, elle considère uniquement la valeur suivante. Dès que les données d'objet sont infectées, nous commençons à calculer la longueur de la liste, à partir d'un nœud principal, parcourons tous les pointeurs ptr «suivants» et comptons simplement le nombre de pointeurs passés. Ainsi, l'algorithme de comptage ne touche pas les données infectées.

Fait intéressant, si vous avez une liste chaînée qui est remplie de données infectées et calcule ensuite sa longueur, cela ne conduira pas à la génération d'une valeur infectée. Cela peut sembler un peu illogique, bien qu'en considérant les tableaux, nous avons déjà dit que la longueur du tableau ne contient pas non plus de souillures. Il y a la même raison. Vers la fin de la conférence, nous verrons comment vous pouvez utiliser un langage qui vous permet en tant que programmeur de déterminer vos propres types d'infection, puis vous pourrez développer votre propre politique pour de telles choses.
Une bonne caractéristique de TaintDroid est que vous, en tant que développeur, n'avez rien à étiqueter, TaintDroid le fait pour vous. Il note toutes les choses confidentielles qui peuvent être une source d'informations, et toutes les choses qui peuvent être des «puits» d'informations, donc vous, en tant que développeur, êtes prêt à travailler. Mais si vous souhaitez contrôler l'ajout de nœuds, vous devrez peut-être créer vous-même certaines stratégies.
Comment TaintDroid affecte-t-il les performances du système? Les frais généraux existants semblent en fait assez raisonnables. La surcharge de mémoire consiste à stocker toutes les balises d'infection. La charge du processeur consistera principalement en la destination, la distribution et la vérification de ces infections, et il convient de noter que l'utilisation de la machine virtuelle Dalvik est un travail supplémentaire. Donc, en regardant la source, en regardant ces informations d'infection 32 bits, nous effectuons des opérations que nous avons déjà considérées. Il s'agit de frais généraux de calcul.

Ces frais généraux semblent assez modérés. Selon les auteurs de l'article, le stockage de balises viciées nécessite 3% à 5% de mémoire supplémentaire, donc ce n'est pas si mal. La charge du processeur est légèrement plus élevée et peut atteindre de 3% à 29% de la puissance de calcul. Cela est dû au fait que chaque fois que la boucle est exécutée, l'interpréteur doit regarder ces balises et effectuer les opérations correspondantes. Bien que ce ne soient que des opérations au niveau du bit, elles doivent être effectuées tout le temps. Ce n'est pas mal, même dans le cas d'une charge de 29%, car les développeurs de la Silicon Valley parlent constamment du fait que les téléphones modernes ont besoin de processeurs quad-core. Le seul problème peut survenir avec la batterie, car même si vous avez des cœurs de processeur supplémentaires, il est peu probable que vous souhaitiez avoir un téléphone chaud dans votre poche qui commence à "exploser" lorsque vous essayez de calculer ces choses. Mais si votre batterie n'est pas particulièrement affectée par de tels calculs, alors tout n'est pas si mal.



C'était donc un aperçu du travail de TaintDroid. Vous avez une question?

Étudiant: ne marquez- vous que ce qu'il y a tout le temps? Ou chaque variable est-elle étiquetée?

Professeur: tout est marqué, donc théoriquement rien ne vous empêche de mettre des informations sur l'infection pour des choses qui n'ont pas du tout d'infection. Je pense que dès que quelque chose obtient au moins une tache, vous devez créer quelque chose comme une disposition de changement dynamique. - , , . taint, , , - , , . , , - . TaintDroid . Dalvik.

– taint x86 ARM? , , , , , , Java . ?

, , , . , , , , , Java- - . x86, , , , , , .
, taint , , , . .



, x86 — . . , - x86, . , , , P, , , !

, taint x86. , , , AD, , .
-, , . -, , . , , , .

, . , . , , , . , « » Taint Explosion.
, , . , Dungeons and Dragons, .

, , - - . , , , .
, - esp esb. , .



, x86, , esp. , , . , , , ebp, , , . , , , taint .

, Linux . , . , - .

: ? , .

: . x86, , . , . Bochs – IBM PC, 86. TaintBochs, x86 . x86, , . , . , , , , , , - .

54:10

Cours MIT "Sécurité des systèmes informatiques". Conférence 21: Suivi des données, partie 3


La version complète du cours est disponible ici .

Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en le recommandant à vos amis, une réduction de 30% pour les utilisateurs Habr sur un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbps à partir de 20 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbit / s jusqu'en janvier gratuitement en payant pour une période de six mois, vous pouvez commander ici .

Dell R730xd 2 fois moins cher? Nous avons seulement 2 x Intel Dodeca-Core Xeon E5-2650v4 128 Go DDR4 6x480 Go SSD 1 Gbps 100 TV à partir de 249 $ aux Pays-Bas et aux États-Unis! Pour en savoir plus sur la création d'un bâtiment d'infrastructure. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?