SecFault.Org

Dans cet article, j’analyse les spécifications de ce logiciel HADOPI et j’explique en quoi il est impossible sans de grave atteinte à la vie privée, la sécurité et la qualité des transfert d’information.

La première fonctionnalité est une politique de sécurité dont la mise en oeuvre est décidée par le titulaire de l’accès. Ce que demande ici HADOPI est ni plus ni moins un controle d’accès discretionnaire (DAC). De plus, rien d’orginial pour une politique de sécurité, elle doit être souple et avoir une granualité fine. Le logiciel se base sur cette politique pour observer (sans enregistrer) les flux et prendre la décision de bloquer ou non ces flux. Ce système est clairement un système de filtrage des flux orienté politique  orienté réseau. Il est demandé qu’il soit aussi bien orienté l’utilisation de listes (blanches, noires, grises) que de l’analyse du traffic (tres orienté analyse de flux et même plus loin DPI).

Ensuite, le logiciel doit être capable d’analyser la configuration du postes, des logiciels, du reseau de manière statique. On peut donc imaginer qu’il va vérifier que vous avez bien défini une clef sécurisé WEP (oui oui WEP c’est sécurisé d’après HADOPI…). Mais là où ca devient fort c’est quand il demande une analyse dynamique des logiciels en fonctionnement soit une analyse dynamique du système ou de l’application. C’est bien beau ça mais tout d’abord pour quoi faire (ça on le fera plus tard) et ils connaissent la difficulté d’avoir un tel dispositif fonctionnant sur un système réel ? Je suis bien placé pour en parler, la mise en place de contrôle d’accès dynamique sur un système pour protéger contre les flux illégaux, c’est le sujet de ma thèse.

Après on a le droit à la killer feature qui va bien avec le DAC, c’est à dire si le logiciel détecte quelque chose d’illégal, il l’annonce à l’utilisateur.

Finalement, de manière générale, la dernière fonctionnalité est la mise en place d’un système de journalisation contenant une version en clair et une version sécurisé qui contient ce qu’a fait le logiciel de sécurisation mais aussi ce qu’il a détecté et ce que l’utilisateur a décidé de faire. Bien sur, le journal sécurisé doit etre confidentielle, authenthique et infalsifiable. En gros, seul HADOPI et l’utilisateur sont senser pouvoir le lire. D’un point de vue sécurité, la fonctionnalité doit donc garantir l’intégrité, la confidentialité et la non répudiation.

Après ca devient fort quand ils demandent que le logiciel puisse lutter contre l’usurpation, le contournement ou l’altération. Mais aussi que toute la structure du logiciel lui meme soit sécurisé .Ensuite, on a le droit au fonctionnalité classique de mise à jour, de faible impact des performances, de désinstallation. On notera que le logiciel peut être fait (ou peut tourner) sur des logiciels libres, c’est gentil de leur part non ? Mais bon vu qu’il faut qu’en même faire plaisir au gros éditeurs, HADOPI précise que le logiciel peut être ajouté dans des suites de sécurité. Quand on voit l’efficacité de ces suites comme les antivirus, ça fait peur…

Comme il a déjà été, le logiciel peut être installé aussi bien sur le PC (ou console ou téléphone, etc) que sur la passerelle, c’est à dire la box en ce moment en France. Mais comme la box est très fermée, peu puissante et renouvellé rarement cette fois n’est que exploratoire. Dans le cadre des grands entreprises, des sondes DPI peuvent également être proposé.

La politique de sécurité doit être générique et universelle. Le logiciel doit être capable d’analyser sans trop de coût un traffic allant jusqu’à 100Mb/s. La modification des listes est possible par l’utilisateur mais ces modifications sont journalisées. Clairement le coeur du système est  l’analyse dynamique des flux réseaux qui sent tres fort le DPI. Mais pour autant, il n’analyse pas le contenu des flux car pour le moment d’après e document ce n’est pas possible d’analyser les attributs de données pour détecter si le flux contient un DRM ou si il est un fichier légal. Ce passage est l’un des meilleurs car il fait directement allusion à un des brevets déposé par Pr. Riguidel qui est justement la personne responsable de ce document. Ils ont même penser aux flux chiffrés en disant que même si ce n’est pas possible de faire une analyse de ces protocoles, une analyse statistique est toujours possible.

Le document explique bien que le logiciel sera pas capable de faire la différence entre un téléchargement P2P d’un ISO Linux et celui d’un film sous copyright. Il doit détecter les piles protocolaires. Par exemple, tout streaming en dehors des sites reconnus comme sur, pourrait être considerer comme illégale. De manière pratique, on peut supposer que le téléchargement HTTP soit interdit sur des sites comme megaupload. Une des autres détections proposée est la détection de VPN chiffré vers des sites problèmatiques, qui a dit IPRedator ?

Le problème de ce logiciel est qu’il doit tourner sur un système controlé par l’utilisateur mais pour autant rester intégre. On a ici un problème non résoluble. En effet, pour fonctionner le logiciel doit faire confiance au système. Hors le système est controler par l’utilisateur et par conséquence ce dernier peut en modifier le comportement. Le logiciel ne pourra donc pas rester intégre. Et encore, même si l’utilisateur n’attaque pas l’intégrité du logiciel, tout virus tournant sur la machine pourra attaquer le dit logiciel. Le coeur du logiciel est d’avoir un journal infalsifiable ce qui est impossible à part en utilisant un TPM et encore j’en doute dans le cadre d’un système controlé à 100% par l’utilisateur.

Ma conclusion est que la mise en place d’un logiciel permettant de faire de l’analyse réseau sur une ligne à haut débit est tout simplement impossible d’un point de vue sécurité informatique car il mélange des concepts qui sont fondamentallement incompatibles. En effet, pour garantir le fonctionnement du logiciel et du journal, il faut faire confiance au système sous jaceant c’est à dire le système d’exploitation. Ce n’est pas possible de faire confiance à un utilisateur. L’utilisateur ayant un controle total du système d’exploitation, le système n’est donc pas de confiance et le logiciel ne peut donc pas fonctionner en restant sécurisé. On pourrait imaginer que l’utilisateur arrive à modifier les alertes à inscrire dans le journal avant qu’elle soit écrite dans ce dernier et donc éviter une détection. Aucun système ne peut protéger un logiciel sur un système d’exploitation non sur sans ajouter une couche plus basse qui est elle meme sécurisé. Par exemple, des logiciels comme Overshadow permettent une telle chose mais en faisant confiance à l’hyperviseur qui controle le système d’exploitation. Ce n’est pas une possibilité ici puisque l’hyperviseur serait également sous le control de l’utilisateur. La seule solution serait d’avoir un système d’exploitation renforcée ne permettant pas à l’utilisateur de fonctionner comme il le souhaite. Un tel système implémentant un control d’accès mandataire et resistant aux utilisateurs est tout à fait possible comme nous l’avons démontré lors du défi de sécurité de l’ANR en proposant un OS qui ne fait pas confiance à l’utilisateur et reste intégre. Mais cela va à l’encontre de la demande de politique discretionnaire car un tel système requiere un politique mandataire. Je ne parle meme pas des problèmes de performances pour l’analyse en temps réel du traffic réseau mais aussi de la protection du système d’exploitation.

Pour finir,  si on fait confiance à des sociétés d’antivirus pour ce logiciel, ca va être un belle blague… De tout façon vu les demandes et les possibilités, il est tout simplement impossible de concevoir un tel système. Tout tentative sera forcement attaquable et le pire c’est qu’au lieu de sécuriser l’utilisateur, il y a de grandes chances que ce logiciel ouvre de nouveau vecteur d’attaque comme nous l’avons vu dans le logiciel GreenDam.

A titre personnel et de recherche, je suis pressé de voir ces logiciels car même en ayant une tres bonne connaissance de l’état de l’art universitaire et industrielles de la sécurité système, je ne vois aucune solution possible qui soit réaliste ! Attendons nous donc à bien rigoler !

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.

Introduction

Les développeurs de Google Chrome ont voulu prendre en compte des aspects de sécurité dès le début pour éviter d’ajouter des couches bancales par la suite. Pour cela, ils ont mise en place une architecture de sécurité relativement élaborée permettant de limiter l’impact des nombreux problèmes de sécurité que peut recontrer un browser lors de ses passages sur des pages web malicieuses. La description de cette architecture est disponible sur le site de chronium (la version libre de Google Chrome). Une partie se base sur des autres travaux de recherche de Google dont j’avais parler ici.

Afin d’améliorer la sécurité de leur browser, ils se basent sur trois régles:

• Limiter la sévérité des vulnérabilités dû aux moteurs de rendu du browser en les plaçant dans une sandbox.
• Limiter le nombre de failles non corrigées et de vieilles versions en facilitant les mises à jours.
• Limiter la fréquence d’expositions aux attaques en annonçant aux utilisateurs quand ils vont visiter un site connu comme malicieux.

Limiter la sévérité des vulnérabilités

Comme je l’expliquai dans l’introduction, Google Chrome utilise une sandbox pour limiter les effets dû à des bugs dans le moteur de rendu (qui est souvent une des manières pour corrompre le browser et l’OS derrière). Cette architecture est décrite en détail dans le billet précédent et est visible dans la figure suivant.

La structure est comme on peut le voir très modulaire. Au final, on se retrouve avec des choses relativement proche des hyperviseurs et/ou des micro-noyaux. Toutes les données sensibles sont stockée par la partie sûre et les rendus sont fait par la partie non sûre. Cette fonctionnalité de sandboxing permet que même si un malware arrive à tourner via une faille dans le moteur de rendu. Son effet sera limité à la sandbox et il ne pourra pas installer un malware ou intéragir en quelques manières que ce soit avec le système.

Ils appliquent également plusieurs méthodes permettant de rendre l’exploitation de vulnérabilités plus dures comme la gestion sûr des erreurs, la non executabilité de la mémoire ou l’allocation de manière aléatoire des plages mémoire.

Chaque origine i.e. site web tourne dans sa propre sandbox. Dans certains cas, plusieurs sites webs peuvent tourner dans le même si il y a des intéractions entre eux. Une sandbox par site web serait mieux mais il faudrait pouvoir gérer les intéractions entre les sandbox. Même si cela est possible suivant des concepts de recherches comme OP et Gazelle, cela est difficile à implémenter de manière efficace.

Reduire la fenêtre de temps des vulnérabilités

Le but est de laisser des failles connues le moins longtemps possible disponible. Pour cela, il faut mettre en place une architecture de mise à jour très efficace. Pour Chrome, dès qu’un bug est détectée, il est corrigée. Puis le patch est testé via les outils de tests automatique de WebKit (le moteur de rendu de Chrome) mais aussi sur 1 millions de pages web de manière automatique.

Les patchs sont ensuite installés automatiquement sur les machines faisant tourner Chrome sans aucune intervention de l’utilisateur ce qui permet une réactivité très bonne sur la correction de failles i.e. voir la figure ci-dessous.

Réduire le nombre de fois que le browser est exposé à des failles

Le but de cette fonctionnalité est relativement simple: prévenir les utilisateurs avant qu’ils aillent visiter un site potentiellement malicieux. Pour cela, Google travaille avec StopBadware.org pour maintenir une base de données à jour de ces sites.

Conclusion

A part la première fonctionnalitée qui est une intéressante d’un point de vue de recherche en sécurité comme je l’avais exprimé dans le précédent billet (même si loin d’être parfaite), les autres sont plus du bon sens. Mais additionner les unes aux autres, elles permettent effectivement d’augmenter le niveau de sécurité du browser.

Bien entendu, il reste de nombreux points à traiter comme la gestion des plug-ins tel que Flash mais on voit que le niveau de sécurité global augmente en appliquant la régle du moins de priviléges possible données à une application.

Références:

Browser Security by C. Reis (Google), A. Barth (UC Berkeley), C. Pizano (Google) – ACM Queue

Après avoir lu plusieurs blogs et news sur Google Native Client, j’ai voulu en savoir plus. Mais n’ayant pas le courage de me plonger tout de suite dans le code, j’ai préféré d’abord lire le papier de recherche fourni par Google. Au passage, si quelqu’un trouve que ce papier a été publié et où ca m’intéresse mais ca n’a pas l’air d’être le cas.

Les auteurs commencent par rappeller que pour faire des calculs ayant des grosses demandent de ressource comme les scenes 3D ou tout ce qui est physique des objets solide et liquides, les langages comme JavaScript ne sont pas adapté. Que même si ActiveX ou NPAPI permet de faire tourner du code natif, c’est au détriment de la sécurité ou en repoussant la sécurité entre le clavier et la chaise ce qui pose souvent de grave problème. Pour eux, l’idée d’utiliser les ressources allouées au navigateur pour faire tourner du code natif d’applications webs est une mauvaise idée.

Alors comment fonctionne leur idée. Tout d’abord, il faut installer un plugin Native Client qui est en faite une sandbox ayant un accés total au système. Ce plug-in tourne dans un processus propre et n’est donc pas liée au navigateur. Les applications webs tourneront dans le plug-in qui intéragit lui-même via des API avec la navigateur et le système. Il est donc possible de concevoir des interfaces en JavaScript qui utiliseront du code natif dans Native Client pour accélerer certains traitements. Par exemple, ajouter des fonctions avancées de traitement d’image dans picassa.

Au final, Native Client ressemble très fortement à un microkernel. Native Client étant la base et l’interface et qui accepte des nouvelles extensions de confiance étendant ses possibilités. Par exemple, il est possible de créer des extensions de confiance qui permettront après à des applications webs d’utiliser le stockage sur le disque. Ce n’est pas l’application qui le fait directement, tout passe par des API.

Mais tout ça ne me rassure que partiellement sur la sécurité de leur architecture. Dans la suite du papier, ils introduisent la notion de double sandbox (une sandbox dans une sandbox). La première sécurité (la sandbox interne) est une première chose qui a l’air vraiment intéressante car elle utilise de l’analyse statique de code (x86 ici) pour détecter et interdire des instructions non sur. En pratique, ils vérifient que les executables inclues uniquement des instructions qu’ils ont qualifié de legales. La seconde sandbox se trouve à l’extérieur et vérifie que l’ensemble des syscalls de Native Client vers le système sont autorisées en les comparant à une courte liste de syscalls (46 dans leur tests). En résumé, l’architecture est donc composé d’une première sandbox qui vérifié la qualité du code et qui appelle une API interne. Puis une seconde sandbox qui vérifie que ce qui sort de l’API vers le système est également valide. Ils utilisent une double analyse dynamique et statique bien que les 2 soient relativement limité car utilisant uniquement des whitelists.

Après ce premier point, il en ressortque la surface d’attaque est assez vaste: la sandbox interne qui fait de la validation de binaire, la sandbox externe qui joue comme un wrapper et intercepte les appels systèmes envoyés à l’OS, les bibliothéques, les interfaces de communications avec les autres modules, le système et le navigateur.

La sandbox interne a été testé via des outils de fuzzing et grâce à un code de seulement quelques milliers de lignes, ils ont réussi une implémentation rapide et sécurisé. La sandbox externe fonctionne en utilisant ptrace et en interceptant chaque syscalls et en le vérifiant contre une whiteliste. Pour certains syscalls comme open, ils vérifient également les arguements pour vérifier que ceux-ci sont aussi autoriser (par exemple ouverture de la lib ld.so).

Avec ces systèmes de sandboxing + des API, il y a forcement un overhead. Ce dernier est tout de même relativement faible entre 12 et 5% ce qui est tout à fait acceptable. Pour tester les performances, ils se sont amusées à porter en Native Code un ensemble de logiciel comme Quake.

Alors? Au final, je trouve que l’idée est plutôt bonne même si l’utilitée est vraiment à prouver. En effet, pour contourner les problèmes des applications webs, on en fait des applications ce qui est un peu un retour au début de la boucle. Mais pourquoi pas ce principe peut être intéressant pour développer les possibilités des applications et leurs puissances sans en complexifier l’utilisation pour l’utilisateur final.

Après je trouve leur idée allant dans le bon sens mais je ne comprends pas pourquoi ils ne les ont pas pousser un peu plus. Sans être un spécialiste du domaine, je suis sur que des travaux beaucoup plus avancés sur l’analyse de code ont été faite que la comparaison avec une whiteliste. De plus, pourquoi comparer les binaires quand la comparaison de code source est tellement plus efficace. Bref, pourquoi ne pas utiliser des logiciels comme FramaC ou d’autres alternatives pour vérifier la qualité du code. Le temps d’analyse sera surement plus long mais de meilleurs qualités et il est toujours possible de l’externaliser (sur un nuage par exemple).

Deuxième point, le contrôle via ptrace des syscalls, alors la pour le coup, c’est vraiment mon domaine et la whiteliste même si elle est intéressante et très limiter. De plus, leur approche ne peut pas résisté à des attaques d’intégrité et/ou de confidentialité complexes incluant des séquences de syscalls. En effet, ils analysent syscall par syscall sans avoir une vue d’ensemble. Mon idée serait d’étendre leur implémentation de ptrace pour le support de label de sécurité à la SELinux (ou d’autres systèmes comme ceux de RSBAC ou GRSecurity) et de mettre en place un système de contrôle d’accés mandataire complet implémentant des fonctions un peu avancée comme le type enforcement. Pour réussir à contrôler les séquences, il faudra des logiciels de prévention des intrusions comme ce qui est développé dans le cadre de l’ANR SEC&SI pour les bureaux graphiques permettant l’accés à Internet.

Biensur, cela va forcément augmenter l’overhead du à l’utilisation de Native Client mais cela peut être minimiser avec une borne achitecture de pre-calcul de la sécurité du code et des droits d’accés de celui

Finalement, en étendant la structure actuelle de Native Code pour remplacer leur analyse statique par des fonctions plus avancés (pouvant très bien être décentraliser sur une grille ou autres nuages) et en appliquant un contrôle d’accés stricte via des propriétés de sécurité (par exemple, tel module ne doit pas pouvoir modifier l’intégrité de tel fichiers ou la confidentialité de tel autres ou l’intégrité d’un autres processus, etc), il serait possible d’avoir un système beaucoup plus résistant aux attaques surement nombreuses et très avancées qui ne manqueront pas d’être développer si cette plateforme à un jour un succés (regarder flash, le pdf, etc).

Google vient de rendre disponible une version expérimentale d’un plug-in pour navigateur web permettant à des applications webs de tourner de manière sécurisé en utilisant du code natif. Ce nouveau plug-in appellé Native Client est distribué sous GPL et est fait pour fonctionner avec la plupart des plateformes et navigateur.

En pratique, Native Client fournit un bac à sable spécialisé pour le web permettant l’exécution de binaires x86. Il fournit également des outils pour faciliter la communication entre JavaScript et les exécutable Native Client. Le but est clairement de permettre aux applications webs complexes de pouvoir faire tourner les parties de code demandant beaucoup de puissance directement en natif alors que le reste restera une application web classique.

Bien entendu, le problème principal de ce genre de solution est que faire tourner du code natif améne à un niveau de risque de rupture de sécurité beaucoup plus grande. Il suffit de regarder ActiveX et le nombre d’exploit qui existent et qui sortent régulièrement. Il ne faudrait pas ajouter un nouveau vecteur d’attaque sur des systèmes qui en ont clairement pas besoin de ça actuellement.

Bien entendu, Google a annoncé que son modéle de sécurité était beaucoup plus robuste que ActiveX et que les fonctions de signature via un système de confiance était de bien meilleur qualité. En gros, d’après Google, on passe avec ActiveX d’une structure où l’utilisateur prend les décisions (et donc il doit prendre les bonnes) et encore où cela ne suffit pas à un système où il n’est pas possible de telles choses même avec un module corrompu. Alors la clairement, devant le peu de clareté, à part, on fait mieux que les autres, il est légitime de se poser des questions sur la réelle qualité de leur implémentation et de leur modéle.

Mais en faisant plus de recherches (en lisant le papier que les développeurs chez Google ont écrit), il est possible de se faire une meilleur idée du fonctionnement interne de Native Client. En effet, ce framework consiste en un ensemble de module qui sont ou de confiance ou à qui on ne fait pas confiance. Chacun a son propre processus et communique avec les autres via un système de RPC (Remote Procedure Call: Appel de procédure à distance i.e. ce qu’utilise NFS par exemple). Chaque module qui n’est pas de confiance est écrit en utilisant un langage particulier permettant de faciliter les intéractions avec les modules de confiance. Ce sont ces derniers qui vont réellement faire les intéractions avec la plateforme sous jaceante (aussi bien le réseau que les contrôles d’accés pour les systèmes de fichiers). Ce containeur (qui est au final proche d’une jail) permet d’imposer des contraintes quand au comportement du module ne disposant pas de confiance et permet également aux utilisateurs de définir de manière précise les permissions qui sont données à ce containeur.

#include <stdio.h>
#include <string.h>
#include <nacl/nacl_srpc.h>

/* Return a clever string. */
int HelloWorld(NaClAppArg **in_args, NaClAppArg **out_args) {

  /* Strdup must be used because the SRPC layer frees the string passed to it. */
  out_args[0]->u.sval = strdup("hello, world.");
  return RPC_OK;
}

/* Export the method as taking no arguments and returning one integer. */
NACL_SRPC_METHOD("helloworld::s", HelloWorld);

// helloworld is invoked when its button is pressed.
function helloworld() {
  try {
    alert(document.getElementById('pluginobj').helloworld());
  } catch(e) {
    alert(e);
  }
}

L’Institut de Recherche en Informatique faisant parti de la fondation de recherche grécques FORTH ainsi que l’institut de recherche sur l’informatique et la communication de Singapoure ont publié un article très intéressant où ils tentent de prouver les nouveaux risques et malwares que pourraient se créer dans les réseaux sociaux.

Les auteurs de l’étude définissent un Antisocial Networks comment étant un système distribué se basant sur les réseaux sociaux et pouvant être exploité par des attquants et diriger pour coordonner des attaques réseaux. Mais ils ne se limitent pas à discuter de ce qu’est un tel type de réseau, ils ont implémenté dans la réalité de tels attaques et montrent comme ces plateformes sociales peuvent être utiliser pour lancer des attaques. Ils se sont limités à Facebook pour développer leur concept d’attaques mais cela peut être étendu à l’ensemble des réseaux sociaux disposant d’une possibilité d’extensions par des tiers personnes.

Mais pourquoi les réseaux sociaux ? Tout simplement parce que de plus en plus de personnes sont inscrites sur ces réseaux, ce qui représentent une base de donnée énorme. De plus, ces réseaux sont découpés en groupe de centre d’intérêt ce qui permet de simplement localisé des cibles. Et finalement, par défaut, les utilisateurs ont tendance à faire confiance à leurs réseaux sociaux ainsi que les applications qui s’y trouvent. L’ensemble de ces raisons montrent la capacité de nouvelles attaques qui peuvent avoir lieu sur de tels sites.

Ce principe d’utilisation du web et des utilisateurs pour lancer des attaques n’est pas nouveau, Puppetnets, proposé en 2006, est également une attaque utilisant les mêmes principes. L’idée est de créer une page avec des milliers de liens pointant vers le serveur cible. Quand un utilisateur va charger cette page, son navigateur va télécharger des milliers de liens et provoquer une sur-charge sur le serveur cible. De plus, si cette page devient virable (un “Slashdot effect” par exemple), le serveur cible va se retrouver sous un DDoS. Bref, une technique simple et efficace pour lancer un DDOS a très faible cout. En ajoutant un peu de Javascript, pour des chargements multiples des liens, la méthode devient encore plus efficace.

Bien que les auteurs aient faire leur expérimentation sur le vrai réseau Facebook, ils n’ont pas développé des fonctions trop invasive (par exemple, l’obligation d’inviter 20 amis a essayé l’application avant de pouvoir l’installer, ce qui semble une méthode classique pour augmenter la popularité d’une nouvelle application) pour éviter de perturber le fonctionnement de Facebook pour les utilisateurs légitimes. Le principe de leur application était d’afficher une nouvelle image tous les jours en provenance du site du National Geographic. Mais également, quatres frames caché qui chargeaient pour 600Kb depuis le serveur de la cible à chaque fois qu’un utilisateur utilisait l’application. Bien sur dans le cadre de leur étude, le serveur était hébergé dans le lab et isolé du reste du réseau.

Bien que la méthode utilisé était relativement simple et pas trop invasive et avec une publicité limitée (i.e. uniquement quelques personnes de la communauté de la sécurité), l’application est rapidement arrivée à plusieurs centaines d’utilisateurs (plus de 1 000 utilisateurs avaient installé l’application en quelques jours) provoquant des pics d’utilisations de bande passante sur le serveur cible allant de 2Mb à 6Mb (entre 100 et 350 requêtes HTTP par second). Ils ont également analyser la provenance des requêtes (i.e. où se trouvent géographiquement l’utilisateur facebook) et on peut voir une répartition mondiale assez propre (ce qui risque de poser des problèmes pour la mise en place de contre mesures).

Ensuite, les auteurs ont voulu évaluer la puissance d’attaque d’une telle application dans la réalité et avec l’ensemble des facteurs qu’ils n’avaient pas voulu utiliser pour éviter de perturber le fonctionnement de Facebook et des utilisateurs. Par exemple, pour des applications ayant 1 millions d’utilisateurs ou plus, il faut s’attendre à des DDoS constants de 23Mbit/s soit 248Gb par jour. Ici, il ne faut pas voir uniquement la quantité de donnée mais le nombre de requêtes HTTP que va devoir résoudre le serveur cible et c’est cela qui risque d’être le point faible (et également celui de rupture).

Maintenant que le risque est prouvé (et pas uniquement limiter à des attaques de type DDoS, ces applications/malware facebook pourrait aussi être utiliser pour scanner des ordinateurs, propager des malwares, etc), les auteurs proposent plusieurs méthodes pour mettre en place des contre-mesures vis-à-vis de telles attaques. Leur première proposition pour se prémunir contre de tels attaques est tout simplement refusé tout traffic entrant ayant comme champ de référée du paquet HTTP facebook.com. Mais cela est relativement simplement contournable. L’une des autres méthodes est “tout simplement” que les créateurs de réseaux sociaux écrivent des API pour les applications qui soient propres et sécurisées et qu’ils vérifient la qualité et le risque des applications qu’ils hébergent.

Pour conclure, il est clair que ce type d’attaque pourrait arriver et que coupler avec une campagne virale, elle pourrait faire beaucoup de mal. Il est également possible d’imaginer une telle attaque ayant pour but de créer une sorte de botnet reposant sur des applications facebooks. Mais je ne trouve pas plus convaincant que ça ce type d’attaque pour des attaques massives car clairement pas assez puissants et temporaires (cela ne marche que le temps que l’utilisateur est sur la page de l’application) mais elle pourrait très bien servir pour de la distribution de malware et/ou de la vol de donnée personnel. Un vecteur d’attaque qu’il faudra surveiller vu l’importance que prennent les réseaux sociaux aussi bien dans la vie privée que dans l’entreprise.

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.