Conférence sécurité GTLL du vendredi 12 décembre 2014

This blog post is in French as the event it relates to is French-only.

Theodo a rejoint le GTLL (Groupe de Travail Logiciel Libre de Systematic) il y a quelques mois.
Ce pôle de compétitivité rassemble académiques et industriels autour de thématiques communes, les logiciels libres dans notre cas.
C’est l’occasion d’échanger régulièrement avec des acteurs du logiciel libre dont les points de vue sont très complémentaires des nôtres.
Voici un bref compte-rendu de la précédente rencontre à laquelle nous avons participé autour de la sécurité, sujet particulièrement d’actualité, l’exemple évident du moment étant les fuites de films de Sony.
Si vous voulez en savoir plus, n’hésitez pas à vous inscrire à la newsletter

Les conférences:

Louis Granboulan : Logiciel Libre et Sécurité

Il est convaincu que le logiciel libre permet d’obtenir de très bons résultats en terme de sécurité du logiciel.
Il a parlé un peu du hardware libre, nous avons demandé s’il y avait de gros projets de lancés sur ce sujet en France.
La réponse fut négative. Louis explique cela par le fait que la France n’a pas les moyens de le faire à son échelle : il faudrait le faire au niveau européen.
Le problème est que les pays européens ne se font pas assez confiance pour de tels projets.

Jean Goubault-Larrecq : Détection d’intrusion avec OrchIDS

Le net est largement vulnérable et il a de plus en plus d’impact dans nos vies. Il nous a présenté un cas d’école avec le ver Slammer qui en 2003 avait fait beaucoup de dégâts.
Ses spécificités étaient une propagation rapide (75 000 machines était infectées en 30 minutes) et une agressivité toute relative puisqu’il se contentait de se propager aléatoirement dans le réseau.
Cela avait malgré tout suffi à augmenter l’activité sur de nombreux serveurs au point de les mettre hors service.
Parmi les conséquences on citera qu’internet était tombé au Portugal et en Corée du Sud et une centrale nucléaire avait même eu son réseau informatique interne affecté !

Jean nous a montré quelques attaques possibles sur une machine avec au passage un petit éloge de Kevin Mitnick, un des premiers hackers et d’une explication sur ses premières attaques. Une bonne façon d’apprendre à se défendre est d’apprendre à attaquer !
De nombreux tutoriels pour apprendre à pénétrer un système existent comme avec le site pentesteracademy.

Vient ensuite la présentation de ORCHIDS.
Le but est d’essayer de prévenir les attaques 0 day en repérant des comportements anormaux.
Comme on ne peut pas savoir comment l’attaque se passera, il faut essayer d’anticiper les comportements de celles-ci afin de détecter des anomalies.

Par exemple ORCHIDS regarde si les processus ne comportent pas de montées en droit irrégulières.
Pour cela ORCHIDS analyse l’évolution autour des uids et gids durant l’excution d’un processus.
En utilisant des automates, ils arrivent à analyser un très grand nombre de cas très rapidement.
Si détection d’une attaque il y a, alors ORCHIDS peut intervenir.
Une des réponses possibles est de tuer tous les processus du user concerné et de supprimer son compte user ! BAM !

Un autre type d’attaque peut être détecté si les logs d’un processus renvoient des erreurs un peu particulières et si en parallèle il y a un écart de l’entropie des processus par rapport aux valeurs statistiquement crédibles.
La combinaison de deux évènements inattendus au même instant correspondent souvent à une attaque.

Model checking by Fabrice Kordon

Il partage le même constat qu’internet est de plus en plus critique dans notre vie.
Il cite en exemple la Domotique, les bourses, le milieu médical ainsi que les futures autoroutes automatiques.
Pour augmenter la sécurité d’un programme il faut essayer de valider son modèle.
Il doit être représenté de manière abstraite, les états étant des vecteurs et les transitions des changements d’état.
Il faut analyser les états potentiellement dangereux de son système.
On parle d’accessibilité d’un état dangereux.
Par exemple, existe-t-il une execution qui engendre une surchauffe de ma centrale nucléaire ?
Lorsque la complexité est trop grande, on peut aussi faire l’analyse via de la logique temporelle : Tout état “surchauffe” est-il toujours suivi par un état “alarme” ?
Tout état “surchauffe” engendre après X unité de temps un état “alarme”. Combien vaut X ?
Une approche quantitative est aussi souhaitable: quelle est la probabilité d’atteindre l’état “surchauffe” ?
Une fois cette analyse faite, il faut analyser la présence ou non de garde-fous face à ces états dangereux.
Existe-t-il un contrôleur qui agit lorsque cet état se réalise ?

Prelude Gilles Lehmann

La sécurité c’est aussi la gestion et la communication des alertes : il existe des formats standard pour la cybersécurité, mais qui ne sont pas encore utilisés par tous les outils.

IDMEF Intrusion detection message exchange format.

IODEF Incident object definition exchange format.

Ce talk ne portait pas sur la sécurité à proprement parler, mais sur l’écosystème de reporting et d’échanges d’alertes de sécurité, autour des différents outils SIEM (Security Information Event Management). Plus que de sécurité à proprement parler, il soulevait des questions très complexes autour de la difficulté de faire fonctionner un modèle économique open-source viable : Prelude est l’un des outils open-source dans le monde des SIEM.

Olivier Levillain ANSSI

Cette présentation portait sur les risques qu’apportent les langages eux-mêmes.
Pour Olivier c’est un sujet qui n’est pas assez pris en compte dans les choix techniques d’un projet malgré ses conséquences pour la sécurité et la fiabilité de celui-ci.
Il nous explique donc qu’un langage peut tromper le développeur avec des faux amis et des pièges.
En particulier, les langages courants (notamment du web !) ne vérifient pas toujours les propriétés attendues intuitivement pour les opérations de base (transitivité, réflexivité, associativité).

Exemple en Javascript (un de ses langages “préférés”):

0 == '0' => True
0 == '0.0' => True
'0' == '0.0' => False

WTF ?

Ou encore un exemple assez énorme en Java (il n’y a pas que le PHP qui réserve des surprises :) )

b1=1000
b2=1000
b1==b2 => false

Explication : “==” compare les objets créés, pas leur valeur

a1=42
a2=42
a1==a2 => true

Explication : les “petits” entiers (-128 à 127) sont mis en cache pour gagner en performance : a1 et a2 correspondent donc au même objet.

La réflexivité n’est pas toujours non plus respectée comme le montre ce tableau :

Les chaines de charactères comportent aussi pleins de WTFs.
Notamment PHP qui fait des conversions de ses strings en float si la chaine commence par l’équivalent d’une description d’un nombre float.

echo "5e1+4rftgh" + "50";

renvoie 100 !

Il nous invite à aller nous divertir sur www.thedailywtf.com.

Un autre exemple d’abus présent sur les langages : les spécifications ouvertes à interprétation.
Par exemple en Java, un extrait de la spécification de la méthode clone :

The general intent is that, for any object x, the expression:
x.clone() != x
will be true, and that the expression:
x.clone().getClass() == x.getClass()
will be true, but these are not absolute requirements. While it is typically the case that:
x.clone().equals(x)
will be true, this **is not an absolute requirement**.

Pas de réelles contraintes, ce qui signifie que potentiellement la fonction peut ne pas avoir un comportement déterministe ce qui est alors impossible à tester.

Mais n’oublions surtout pas sa conclusion: “Le ruby est le pire de tous”. (Ouf.. :) )

Conclusion

Que peut-on retenir de tout cela en tant que développeurs web ?
D’abord la diversité de ce que l’on peut entendre par sécurité.
En effet chaque projet a ses propres besoins de sécurité.
Il faut savoir trouver le bon équilibre entre sécurité et fonctionnalités.
Un projet avec trop de peu de sécurité menera à un désastre.
Un projet avec trop peu de fonctionnalités ne sera pas utilisé.
Il faut donc pouvoir aider le client à détecter les points critiques d’un projet afin de les protéger au mieux.
La loi de Murphy s’appliquant particulièrement bien à l’informatique, il faut savoir prévoir le pire !

Pour conclure, une liste de bonnes pratiques de sécurité pour vos projets PHP et un lien vers
l’Open Web Application Security Project une association mondiale pour promouvoir la sécurité des logiciels.