SecFault.Org

Lors de la prochaine conférence SIGOPS sur les principes fondamentaux des systèmes d’exploitations (SOSP’09), les nombreux auteurs (Andrew Baumann (ETH Zurich), Paul Barham (MSR Cambridge), Pierre-Evariste Dagand (ENS Cachan Bretagne), Tim Harris (MSR Cambridge), Rebecca Isaacs (MSR Cambridge), Simon Peter (ETH Zurich), Timothy Roscoe (ETH Zurich), Adrian Schüpbach (ETH Zurich), Akhilesh Singhania (ETH Zurich)) vont présenterun papier intitulé: The Multikernel: A New OS Architecture for Scalable Multicore Systems.

Ce papier présente une nouvelle architecture pour les systèmes d’exploitation. Tout d’abord, malgré la présence de nombreuses personnes de Microsoft Research, le système d’exploitation qui en résulte, n’est pas du tout un Windows mais un bien un nouveau système d’exploitation. Ce système n’a pas pour but d’être utilisable mais il présente une nouvelle architecture. C’est un OS d’expérimentation uniquement qui n’ira surement pas plus loin que le prototype. Néammoins, il est possible que certains principes soient ensuite utilisé dans des systèmes fonctionnels.

Le principe de cet OS est de pouvoir passer outre le problème actuel que les OS rencontrent de plus en plus: la synchronisation des coeurs dans les systèmes massivement multicoeur et l’hétérogénité du fonctionnement hardware des processeurs multi-coeurs. Par hétérogénité hardware, les auteurs veulent parler du fonctionnement différents des multicoeurs proposées par les acteurs du marché (Sun, Intel, AMD). En effet, chacun utilise un fonctionnement différent sur les communication inter-coeurs avec des controleurs de mémoire à différents niveaux.

Les OS actuelles permettant la prise en charge de coeur multiples fonctionnent en utilisant une mémoire partagée pour l’échange d’informations mais également le stockage des données. En introduisant leur architecture multikernel, les auteurs proposent une communication explicite (contrairement à celle implicite via le partage de mémoire) en utilisant un système de message. Cela leur permet d’éviter que la mémoire partagée deviennent un goulot d’étranglement. Les études récentes montrent qu’au delà de 80 coeurs, le partage de la mémoire devient critique. Le système par message doit permettre de passer outre ce problème. Il se base sur un système de type RPC et a une complexité qui est linéaire mais également largement inférieur à celle du système par mémoire partagée. Dans le cas du multikernel, chaque coeur et chaque noyau se retrouve avec un espace de mémoire dédiée et partage donc les informations par un système de message proche de celui de RPC et très compacte (64bit).

Le principe de leur architecture est un système distribué communiquant avec des messages et sans partage de mémoire. Le partage de lock ne fonctionne plus par une structure unique de donnée se situant dans la mémoire partagée mais par un lock répliqué autant de fois que de nombre de coeurs accédant à la donnée et synchroniser via des échanges de messages. Le système de message est au final relativement proche de celui des micronoyaux et tout particulièrement celui de L4.

Pour conclure, c’est un nouveau model très intéressant et qui propose une nouvelle solution pour mieux prendre en compte les machines multicoeurs. D’un point de vue de la sécurité, toutes les communications entre coeurs étant explicites, cela devrait pouvoir faciliter le travail pour détecter des fluxs d’informations illicites. En se basant sur des principes de micronoyau, on peut espérer que la sécurité amenée par ce modèle pourra également améliorer la sécurité du multikernel. C’est bien un OS à surveiller si son développement continue contrairement à la plupart des projets de recherche qui ne sont rarement développé très longtemps.

The multi-principal OS construction of the Gazelle Web Browser est un papier publié à USENIX Security par une équipe commune Microsoft Research, University of Illinois et University of Washington. Leur papier décrive l’architecture qu’ils proposent pour un navigateur plus sécurisé et plus résistant aux nombreuses attaques qui existent actuellement quand vous surfez sur des simples pages Internet.

On peut dire que Gazelle est la réponse de Microsoft à plusieurs technologies de Google qui sont rassemblée dans Google Chrome (et Google Native Code). Le but dans les deux cas n’est plus de voir le navigateur comme un gros programme d’affichage de pages mais comme un OS dédié à la navigation. Dans ce cas, le navigateur est séparé en plusieurs processus qui sont controlés par un noyau.

Le noyau comme le noyau d’un OS se charge de la communication entre les différents composants et processus mais aussi gére l’interface avec les ressources systèmes. En compartimentant les différents pages vu simultanéement i.e. avec un processus par tab, si une page plante ou est corrompu, le problème sera limité à une page et pas la totalité de celle actuellement affichée.

Cette méthode a été rendu grand public par Chrome mais d’autres browsers expérimentaux comme OP ou Tahoma proposaient déjà des structures similaires.

La différence entre Gazelle et Chrome est au niveau de la finesse de séparation entre les différents domaines Internet. Le but est toujours d’éviter au maximum que des données d’un site soit lu par un autre et la séparation jusqu’au rendu de la page est essentielle. La même chose doit être appliquée pour les plugins qui sont de plus en plus source de problèmes.

Pour conclure, Gazelle est un très beau principe qui  promet une meilleur sécurité au niveau du navigateur. Des inconnues restent comme le principe de sandboxing pour éviter qu’un processus corrompu perturbe le système ou la gestion des plugins mais leur idée est très intéressante.  Avec la montée des applications web et des données de plus en plus sensibles qu’elles traitent la sécurité du navigateur est un point essentiel et l’un des plus attaqués actuellement. Il est probable que de telles architectures tentent à se démocratiser dans les années à venir pour ce genre de logiciel.

Les auteurs de “Effective and Efficient Malware Detection at the End Host” publié à USENIX Security 2009 sont partis du faite qu’il y a de plus en plus de malwares et qu’ils collaborent de plus en plus entre eux. De plus, les antivirus actuelles se basent essentiellement sur les signatures qui sont facilement contournées en utilisant du polymorphisme  ou de l’obfuscation. D’autres méthodes, plus marginales, se reposent sur l’analyse des séquences d’appels systèmes générés par un programme mais sont contournable en changeant de manière légére la séquence de ces appels. Finalement, des méthodes ont été proposées afin d’extraire des comportants globaux à une famille de malware pour les bloquer d’une manière plus efficace, mais ces méthodes ne sont pas assez rapide pour fonctionner en temps réel. Le but des auteurs est donc de proposer un système qui va réellement pouvoir détecter les derniers malwares actuelles et tout cela en temps réel.

Leur système permet tout d’abord de générer automatiquement un modèle du malware ou de la famille de malware. Ce modèle se base sur des informations très compléte du comportement du malware. Contrairement à la détection par signature, où souvent seulement un hash du malware est utilisée pour la détection ou de la détection par séquence d’appels systèmes où cette dernière doit être respecté pour que la détection fonctionne, le modèle conserve l’intégralité des informations relatives au comportement du malware et pas uniquement une partie. D’après les auteurs, cela permet d’éviter les risques de non détection quand les malwares utilisent l’obfucation ou le polymorphisme. Ils ont ensuite développer un scanneur qui permet de faire correspondre un modèle à un programme inconnu. Pour cela, il se base sur la dépendance entre des appels systèmes.

L’une des nécessités que se sont imposée les auteurs dès le début, c’est que leur système ne devait pas incorporer de connaissances au début mais plutôt les développer au fur et à mesure. En effet, il devient tellement simple de générer des nouveaux malwares que toute connaissance preliminaire est caduc très rapidement. Bien entendu, les auteurs ne peuvent qu’admettre que dans ce cas, il faut qu’un malware soit analysé au moins une fois pour que son modèle soit généré et détecté par la suite. Il faut donc que le malware soit détecté par un tier, puis analyser par le système de génération de modèle pour pouvoir servir à la détection. Les auteurs précisent que ce n’est pas nécessaire pour chaque malware et chaque déclinaison de celui-ci grâce à leur modèle qui permet d’avoir des informations précises.

Afin d’améliorer leur système, leur analyse se base sur l’analyse d’un sous ensemble qualifié d’intéressant de syscall qui pourraient réellement aider à la détection de malware. Une fois les syscall collectés, ils les utilisent pour créer un graphe orienté qui va lié deux noeuds i.e. deux syscalls si les données générées par le premier sont utilisées en entrée par le second.

Leur système fonctionne plutôt bien quand il s’agit de détecter des malwares et des variantes de ces derniers qu’il a déjà analysé. D’après les tests fournis par les auteurs, le taux de détection est de 90% avec un taux nul de faux positif. Mais dès qu’il s’agit d’analyser des variantes inconnus le taux de détection chute à seulement 25%. Leur système se basant sur des modifications du système pour pouvoir monitorer, analyser et bloquer des programmes au niveau noyau, un driver ainsi qu’un certain nombre de programme ont été développé. L’overhead est relativement faible 10% pour ce qui est du CPU mais il monte rapidement pour les entrées/sorties et 40% pour des tâches complexes comme une compilation.

Pour conclure, leur système est intéressant car il permet effectivement une bonne détection de comportement des malwares en se basant sur l’observation des liens entre syscalls. La méthode permet donc d’éviter les problèmes d’obfuscation, de polymorphisme mais aussi de changement d’ordre des syscalls. Par contre, leur méthode ne détecte que péniblement les variantes d’un malware déjà connu et ne détecte pas à l’avance des inconnus. Le système est donc en effet une progression par rapport aux systèmes existants mais a encore de grave lacune pour qu’ils soient utilisables.

Pouvoir détecter si un système est virtualisé ou non est utilisé pour deux raisons majeurs: tout d’abord pour détecter si un malware accéléré hardware de type BluePill est installé sur la machine mais aussi pour les programmeurs de malware de vérifier que leur programme ne tournent pas dans un environnement virtualisé. Mais pourquoi ce deuxième point est important ? Parce que la plupart des personnes analysant les malwares pour générer des signatures qui vont permettre aux antivirus de détecter le malware utilisent des outils d’analyse comportementale qui sont inclus dans des logiciels de virtualisation. En pouvant détecter la virtualisation, les malwares peuvent donc rester plus longtemps sans être détecter.

La proposition des auteurs (R. Paleari, L. Martignoni, G. F. Roglia et D. Bruschi) du papier “A fistful of red-pills: How to automatically generate procedures to detect CPU emulators” publié à USENIX Security 2009 est de lancer une série d’instructions dans l’environement virtualisé et les mêmes dans un environement normal. En analysant la différence, ils sont capable de générer automatiquement des outils de détection de la virtualisation (i.e. les fameux redpill). Ils ont réussi à générer automatiquement près de 21 000 redpils pour QEMU et 3000 pour BOCHS.

La découverte automatique d’instructions n’ayant pas les même retour entre un CPU réel et un CPU virtualisé est fait en se basant sur le programme EmuFuzzer.

Ce speach fait à la Black Hat USA 2008 par Rafal Wojtczuk (Invisible Things Lab) a pour but de présenter deux attaques sur l’hyperviseur Xen: une dans le code de Xen et une autre dans un domaine caché. La motivation de l’auteur est de dire que dans quelques années tout le monde aura un hyperviseur par défaut sur son ordinateur. Il n’a pas faux car, par exemple, Dell commence à fournir par défaut sur ses serveurs VMWare dans une ROM donc je peux imaginer dans quelques années que dans une puce, un hyperviseur soit disponible par défaut (il faut bien les utiliser tous ces coeurs). De plus, si il est possible d’attaquer ces hyperviseurs alors on se retrouve avec le même cas de figure qu’avec le virus Bluepill.

La première méthode d’attaque est de modifier depuis le système contenant l’hyperviseur (le Linux “maitre”) la mémoire contenant les informations à propos de Xen. Normalement un tel accés est protégé, mais en utilisant une technique similaire à celle présenté à SSTIC et permettant d’éxecuter du code via un iPod, l’auteur propose ici de s’attaquer au DMA et au carte réseau pour récupérer des valeurs en mémoire. La deuxième méthode utilise la possibilité de créer des domaines (et donc des machines virtuelles) qui peuvent espionner les autres et donc modifier leur données mémoires en temps réels.

Ces deux méthodes sont bien décrites et semblent tout à fait réalisable mais Xen n’est que peu utiliser actuellement. Des attaques de ce type sur VMWare seraient intéressante à voir également mais il n’empêche que les méthodes proposées ici utilisent  des concepts généric de la virtualisation est pourrai être utiliser sur d’autres hyperviseur.

Déjà quand on commence à parler de Cloud Computing, je ne peux m’empêcher de penser au soit disant Web 2.0, un nom totalement marketing, alors est-ce le cas ici ? Déjà, on peut en douter, la présentation de cette outil a été faite lors de USENIX Security 2008 par J. Oberheide, E. Cooke, F. Johanian de l’Université du Michigan. Leur but est de combiner une dizaine d’antivirus et deux applications de détection comportementale et de fournir l’ensemble de cette détection comme un service de type Cloud Computing. Le client n’a donc qu’à installer un petit client léger pour le service et le serveur se charge des outils de détection. D’après leurs études, il est possible d’avoir une réelle meilleur détection (35% de plus) en utilisant leur méthode. Cette méthode, ils l’ont expliqué lors de leur présentation.

Pour motiver leur travail, ils sont parti de deux faits: tout d’abord, il y a de plus en plus de virus et il devient presque impossible de tous les détecter dans le meilleur délais, mais aussi, les antivirus deviennent de plus en compliquer et deviennent des vecteurs d’attaques. Leur solution se base sur deux points forts pour éviter ces problèmes: tout d’abord, l’antivirus comme un service, où chaque machine ne fait plus tourner un antivirus mais fournit le fichier à analyser et qu’un serveur ‘dans le cloud’ se charge de l’analyser. De plus, ce serveur ne fait pas tourner une version d’un antivirus mais plusieurs antivirus et outils de détection afin d’atteindre le meilleur niveau de détection. Les quatres avantagesde leur solution sont:

• une meilleur détection
• des capacités de forensic i.e. le serveur peut garder une trace de qui a analysé tel fichiers à tel heure.
• des possibilités de savoir dès l’arrivée d’une nouvelle signature qui avait été infecté et résoudre le problème (en gardant trace des fichiers que chaque client a envoyé).
• facilitation de la mise en place et de la maintenance grâce à un service déporté dans le “cloud”.

Leur architecture se découpe en trois composants majeurs: un client léger, un service web de réception des fichiers et un service d’archive et de forensic qui garde les informations à propos des fichiers analysés. Ils ont implémenté et testé ce système pendant 1 an. Dans leur papier, ils montrent clairement les chiffres de leur étude, et même si leur système est loin d’être parfait, il apporte des idées intéressantes.

Reste à voir le problèmes de la propriété privé, en effet, les fichiers sont envoyés à une entité centrale mais aussi l’importance de l’impartialité et de la sécurite de cette structure centralisée.

Le problème de la détection et de la défense contre les DDoS est un problème aborder dans les conférences de sécurité depuis des années et malgré des solutions qui marchent plus ou moins aucune alternatives simples d’utilisation n’a jamais pu être proposé. Et pour cause, ces attaques massives sont souvent massivement distribués et donc difficile à bloquer. De plus, il ne faut pas bloquer les connexions légitimes pour permettre aux utilisateurs de continuer à accéder aux services pendant la période d’attaque. La plupart des solutions se basent sur des statistiques et un certain nombre de variables à fixer suivant le matériel des serveurs et du réseau. Ici, les 4 auteurs (J. Chou, B. Lin, S. Sen, O. Spatscheck) de l’univeristé de Californie et de AT&T proposent une solution reprenant ces principes mais permettant de limiter les dégats collatéraux (i.e. le nombre de connexion légitime qui n’aboutissent pas).

L’importance des attaques DDoS n’est plus à prouver, de nombreux cas d’attaques à plus ou moins grande échelle a déjà eu lieu avec une apogée avec l’attaque de l’Estonie mais également récemment les sites du gouvernement Géorgien. Avec des botnets de plus en plus gros (et de plus en plus simple à louer) mais également avec l’augmentation de la rapidité des connexions, il est possible de voir s’effectuer une telle attaque sur des grosses structures avec plusieurs dizaines de Gb de bande passante. Leur but est de pouvoir limiter l’impacte de tel impact en faisant une séparation en les flux de traffic et en séparant les “mauvais des bons”. Pour cela, ils utilisent un mélange de récupération de données sur le traffic, de bandes passantes répartites suivant des mesures de traffic, la mesure et le marquage de packet réseau en se basant sur la capacité d’allocution disponible et perdre des packets quand la capacité du lien réseau est dépassé.

De plus, leur méthode permet d’être totalement invisible quand il n’y a pas de DDoS et fonctionne sur le matériel qui est actuellement déployer (pas besoin d’en changer/racheter). Leur solution se base sur un algorithme (CDF-PSP) qu’ils ont développé et permet de réduire de 53% le nombre de packet perdu (soit environ 59% des flux).

Pour conclure, une présentation qui mélange aussi bien un cas pratique qui arrive tous les jours, avec des expérimentations réelles sur un grand réseau (plusieurs dizaines de Gb/s) et un bon niveau scientifique. Après leur méthode n’est applicable que par les grands ISP mais si elle est aussi efficace dans le monde réel que ce que les auteurs avancent alors cela devrait non pas résoudre mais aider à se réduire le problème des DDoS de grande ampleur.

C’est d’abord Tal Garfinkel de VMWare a DIMVA qui nous avait parlé de leur idée de créer des API pour VMWare permettant de placer l’antivirus/IDS en dehors de la machine virtuelle au niveau de l’hyperviseur, puis un renforcement de cette idée avec des détails par un autre employé de VMWare lors de la Defcon, c’est à la Black Hat USA 2008 qu’une autre société Fouteenforty Research Institute (Japan) a présenté (Junichi Murakami) leur propre Hyperviseur IPS pour les technologies de virtualisation. Le potentiel de VMWare au niveau buzz commercial et fonctionnalité de la “mort qui tue” n’est plus à prouver donc est-ce ici le cas ou non ?

L’auteur commence par montrer que maintenant, les malwares sont développées tellement dans le noyau que les antivirus/malwares/rootkits ne sont plus à un niveau supérieur à ces malwares mais au même niveau. Le combat devient donc de plus en plus compliqué voir impossible (il suffit de voir le nombre de virus étant non détecter). Après un retour assez technique sur les différentes malwares avancés sous Windows, l’auteur rappelle le fonctionnement des nouvelles techniques de virtualisation hardware comme Intel VT. Et enfin, la présentation de la solution en elle-même (uniquement Windows XP SP2 pour le moment) qui est un IPS qui tourne en dehors de l’hôte sur un hyperviseur (comme l’hôte) et qui permet de protéger le kernel mais aussi d’observer et de controller le système. Leur IPS (Viton) utilise Bitvisor, un hyperviseur Windows XP/Vista du même type que Xen et développé par une université (Tsukuba) au Japon.

Les fonctionnalités de Viton sont de pouvoir protéger et bloquer des instructions émisent par l’hôte ainsi que d’autres protections mémoires spécifiques à Windows. Mais ce qu’il ne fait pas c’est protéger les systèmes de fichiers ce qui pose bien sur un gros problème. Au final, on se retrouve avec un début d’idée, pas beaucoup de limitations réelles (mais quelques unes bien spécifiques à la manière de fonctionner actuelle des malwares) et aucune informations sur les expériences et la sur-utilisation et capacité réelle de leur solution dans un envirronement réelle.

Pour conclure, on ne peut qu’attendre de pouvoir essayer dans des cas réelles et sur des HoneyPots de tels systèmes mais également de trouver des failles et autres dans ces approches. Mais si une telle alternative à notre solution d’antivirus/HIDS se développer, c’est les grandes sociétés d’antivirus qui devront voir à moyen terme à changer leur méthode de fonctionnement. Pour le moment, cette nouvelle approche reléve plus du buzz marketing spécial BlackHat / conférence qu’une alternative réelle.

Smack qui est un système de contrôle d’accés “simple” et “simplifié” sous Linux et implémenté sous la forme d’un LSM comme SELinux est également plus léger que SELinux. Partant de ce constat et du défit au niveau sécurité que sont actuellement (et seront encore plus) les dispositifs éléctroniques, l’auteur Casey Schaufler veut montrer comment adapté Smack au monde de l’embarqué.

Je ne vais pas revenir sur ce qu’est un système MAC ou sur l’importance de l’isolation des processus les uns par rapport aux autres. Le seul petit problème de leur introduction est de dire que SELinux n’est pas adapté aux dispositifs embarqués alors qu’un papier dans la même conférence montrer le contraire mais il ne pouvait pas savoir en même temps.

Sa présentation commence par un rappel de ce qu’est Smack, de son intérêt par rapport à SELinux (plus simple, plus léger), etc ce qui n’est pas un mal vu le peu de docs disponibles pour Smack. Puis après avoir fait un rappel relativement similaire (à la présentation sur SELinux dans l’embarqué) aux problèmes qu’apporte l’embarqué, l’auteur a décidé d’orienter plus précisément son étude vers les téléphones qui est surement LE domaine à venir de Linux.

D’un point de vue sécurité, un téléphone pose de nombreux problèmes, par exemple, un utilisateur peut très bien installer un programme fait par lui ou une tierce personne. L’embarqué pose déjà des problèmes mais si en plus il est possible d’ajouter des programmes non vérifiés, la sécurité des services sur le réseau téléphonique peut ne plus être assurés (ou tout du moins pas comme les fournisseurs téléphones le voudraient i.e. par eux). Grâce à un système MAC, on peut allouer une politique spécifique à chaque application et donc limiter son accés au réseau et/ou au périphérique du téléphone (e.g. l’application de solitaire n’a pas besoin de pouvoir téléphoner).

Pour conclure, bien que Smack soit intéressant et que la sécurité dans l’embarqué soit un point essentiel de la sécurité qui risque de se développer dans les années à venir, cette présentation ne me convaint pas après la possibilité afficher par l’équipe de Fujisu de pouvoir utiliser SELinux dans l’embarqué. Leur solution fonctionne et n’est pas un bout de spécification papier, beaucoup de documentations existes déjà pour SELinux et sa qualité a déjà été testé alors que Smack est beaucoup plus jeune. Mais, c’est surement une conclusion biaisé par mon utilisation de SELinux dans mes recherches et donc mon habitude de ce dernier.