Sygus.net

Le SSTIC 2010 s'est terminé sur une remarque intéressante concernant la tendance qu'à la communauté de la sécurité à privilégier la recherche de vulnérabilité au détriment de l'élaboration de systèmes réellement sécurisés. Je pense qu'il faut distinguer deux choses :

• la vision court terme : l'analyse de sécurité d'un système spécifique (site web, applications, COTS, etc.) et la nécessité, pour faire bouger les choses, de démontrer que des vulnérabilités sont effectivement exploitables ;
• la vision moyen/long terme : la nécessité de créer des cadres sécurisés dans lesquels des erreurs de développement ou d'utilisation ne mettent pas en péril la sécurité des systèmes.

Je crois moyennement à l'éducation des utilisateurs et des développeurs aux bonnes pratiques de sécurité (hormis à quelques règles de base, et encore...). Même après de nombreuses séances de sensibilisation, de formation, ou de démonstration, par l'exemple, de l'existence de vulnérabilités, il restera toujours quelques personnes qui coderont avec les pieds, introduisant alors une faille dans le système. Bref, l'éducation de 100% des gens aux bonnes pratiques me semble illusoire comme objectif et comme horizon pour que la situation s'améliore significativement.

Il faut plutôt considérer les utilisateurs et développeurs d'applications comme des sources potentielles de vulnérabilités. Je pense donc que le petit monde de la sécurité doit avant tout s'atteler à créer des cadres dans lesquels les utilisateurs et les développeurs peuvent se tromper, faire des erreurs, sans mettre en péril la sécurité des systèmes. Autrement dit, créer des systèmes tolérants aux failles et créer des environnements de développement empêchant de coder avec les pieds. Les différents guides de bonnes pratiques et de recommandations sont biensur intéressants et nécessaires. Cependant, un vrai environnement de développement sécurisé devrait être capable d'imposer de lui-même ces règles. La porte dérobée introduite involontairement dans le challenge SSTIC est un exemple typique d'erreur de développement. Un environnement de développement sécurisé devrait être capable de détecter, par exemple, de telles mauvaises utilisations d'API crypto.

Pour des systèmes tolérants aux failles, il s'agit notamment d'atténuer le risque d'exploitation. Voici quelques exemples de mécanismes ou de pistes qu'il est pourtant possible de mettre en place pour tenter de se protéger des programmes vulnérables :

• activer les différents mécanismes qui rendent difficiles les exploitations en mémoire (bit NX, DEP, PaX, ASLR, canaris, UDEREF, etc.) ;
• mettre en place ces mêmes mécanismes au niveau noyau ;
• sandboxer les processus (chroot, SECCOMP) et les drivers (avec l'IOMMU) ;
• limiter les droits des processus (capabilities sous Linux, etc.) ;
• sortir des systèmes monolithiques (dont la moindre faille dans un driver ou une sous-partie obscure du noyau expose l'ensemble du noyau), pour utiliser des OS à base de micro-noyau (L4, Hurd, Coyotos, etc.) combinant les principes de moindre privilège et de minimalité ;
• etc., etc. ;
• d'autres mécanismes restent encore à imaginer !

Il existe des OS ou des prototypes d'OS durcis (Qubes, Gentoo Hardened, SeL4, etc.). Ces exemples doivent devenir la norme dans les futurs déploiements ou devenir la base de travail pour les futurs OS opérationnels.

Le microcosme de la sécurité informatique avait rendez-vous les 4, 5 et 6 juin à l'université de Rennes 1 pour une nouvelle édition du SSTIC. L'occasion pour des personnes d'horizons divers d'échanger et de présenter leurs recherches. Comme chaque année, et ce depuis 6 éditions (la 3ème pour moi), l'équipe du SSTIC nous propose une brochette de conférences couvrant les principaux thèmes de la sécurité des systèmes d'information : un peu d'organisationnel et de juridique, des présentations de projets (ERESI, GenDbg, SinFP) et pas mal d'analyses techniques avec aussi bien de la crypto, de la virologie, du reverse que des attaques matérielles, applicatives ou systèmes. L'accent a été clairement mis sur les techniques d'analyses statique et dynamique de code avec des conférences sur des méthodes de rétroingénierie et de déboguage noyau/processus. Des techniques très intéressantes, qui servent aussi bien les intêrets des attaquants (compréhension des vulnérabilités en analysant les patchs de sécurité) que des défenseurs (analyse de malwares pour comprendre comment ils se propagent sur nos systèmes).

En vrac, les points à retenir (ou pas...) :

• la possibilité de faire évader de l'information grace aux variations de la vitesse de rotation sur les ventilos des processeurs.
• Debian en a pris pour son grade à propos de la faille OpenSSL.
• ivanlef0u n'est pas un bot IRC.
• le bus Firewire doit définitivement être supprimé sur les machines. Bon ok, l'accès à la mémoire physique par DMA n'est pas nouveau, mais les utilisations possibles sont assez sympas.
• il faut tout faire pour éviter les zombies.
• le piégeage de processeur offre pas mal de possibilités d'attaques. Mais bon, si on va dans ce sens, on peut imaginer tout un tas de backdoor matérielles. A mon sens, l'hypothèse de départ est quand même à la limite d'être réaliste.
• stopper les grands réseaux d'envois de spams/malwares est une utopie à partir du moment ou certains domaines et/ou plate-formes d'hébergements se situent dans des zones juridiquemet inatteignables.
• chez INL, ils s'amusent plutôt bien.
• le patch pour l'attaque de -nikoteen est le suivant : "so strong, that I can't get through". Et ça marche !!

Un point important cette année, est la volonté de pas mal d'équipes de recherche de diffuser librement les sources de leurs projets. Je pense notamment aux projets ERESI et SinFP, de même qu'à plusieurs outils présentés pendant les rumps sessions. De plus, en regardant les portables présents dans le public, il est frappant de voir qu'un bon nombre utilisent des OS libre, typiquement Linux, avec une majorité de Debian et d'Ubuntu. Il est donc clair que la communauté du logiciel libre est plutôt bien représentée dans le monde de la sécurité. J'ai d'ailleurs croisé quelques têtes aperçues au FOSDEM et aux RMLL.

Plus généralement, il est intéressant de voir que la sécurité "ouverte", par opposition à la sécurité par l'obfuscation, est prédominante dans ce genre de conférence. Le logiciel libre a donc un rôle important à jouer, aussi bien pour assurer l'indépendance technologique d'un état ou d'une société vis-à-vis de solutions propriétaires étrangères, que pour permettre une maîtrise du code exécuté, ce qui est d'autant plus important pour des solutions de sécurité. Et quoi qu'en disent les détracteurs du logiciel libre, qui ne se privent pas de rappeler leurs limites comme dans le cas de la faille OpenSSL/Debian, il n'est pas certain qu'une boîte diffusant un logiciel propriétaire similaire aurait annoncé publiquement et aussi rapidement les détails et les implications d'une telle vulnérabilité. Laissant ainsi leurs utilisateurs dans la méconnaissance du risque qu'ils encourent.

Le contexte légal et politique s'est également fait sentir lors de ce SSTIC, mais moins que l'an dernier, avec quelques remarques et questions du public concernant notamment les limitations que la loi nous impose quant aux investigations sur des binaires. En effet, la loi n'autorise le desassemblage que dans une optique d'intéropérabilité logicielle... et même pas matérielle (!). A ce sujet, je me demande si l'auteur d'un malware peut attaquer en justice une boîte qui aurait desassemblé son programme afin d'en étudier son mécanisme... Bref, qu'en est-il des labo de recherche par exemple chez EADS ou au Celar et de leur légitimité à faire du reverse ? Les intervenants du Celar ont malheureusement rapidement éludé la question.

Finalement, nous avons eu un SSTIC très bien organisé (avec une amélioration notable de l'enregistrement du mecredi matin !), une très bonne ambiance, que se soit pendant les confs, pendant les rumps ou lors du social event. Dommage que beaucoup soient repartis sur Paris rapidement, car la soirée du vendredi soir était... mémorable