SecFault.Org

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);
  }
}

Un petit boitier produit par TrueCall doit permettre de lutter contre le “cold calling”, par exemple, le téléphone sonne une fois, vous rappellez, c’est un numéro surtaxé. Je pense que tout le monde a eu ce genre de coup de fil ou de sms du même gabari.

Le système est relativement basique et utilise des méthodes déjà bien connu. Tout simplement, il intercepte tous les appels que vous recevez. Puis si il reconnait le numéro comme un ami (i.e. qu’il est dans la whitelist), il les laisse passer normalement. Si le numéro est sur la liste blacklist par exemple des sociétés de télémarketing, le boitié répond à l’appel et tous les autres aussi et leur envoit un message automatique.

Si le numéro n’est pas reconnu dans l’une des deux listes, la personne qui appelle doit laisser son nom. Puis le téléphone de la personne ayant le boitier reçoit le nom et décide ou non de répondre.

Des mises à jour automatique des listes via un serveur centrale est prévu mais pas encore possible pour l’instant du à des problèmes de législation.

Au final, ce boitier pour un prix de 99£ ne fournit qu’une téchnologie très basique et sans réelle innovation. Ce n’est qu’une évolution très mince par rapport à un affichage du numéro et deux secondes de réflexion et tout ça pour 99£, je trouve ça un peu élevé.

Par contre, le spam téléphonique et SMS se développant, des produits de ce type en software sur les nouveaux types de téléphone (iPhone, Android, etc) pourraient devenir de plus en plus courant et développer un nouveau secteur.