SSTIC 2012 - Successes and limitations of binary static analysis

par @halvarflake

L’orateur travaille depuis 10 ans sur l’analyse de binaire dans l’objectif de découvrir des vulnérabilités. Bien que les choses progressent dans ce domaine, la route est encore longue et les avancées très limitées finalement.

La plupart des avancées sont due à l’existance d’attaquant malicieux qui ont forcé les éditeurs à s’intéresser à ces techniques de recherche de vulnérabilités en y plaçant plus d’argent. Le concolic testing, combinaison d’analyse statique & d’execution symbolique à permis de découvrir de nombreux bugs dans le kernel Windows notament (approche de SAGE, KEE n co).

Le problème c’est que ce sont des outils qui semblent très puissants mais dont l’usage semble très limité aux yeux des professionels. Et l’analyse statique échoue souvent à cause d’erreurs faites systématiquement par ceux qui mettent en oeuvre ce genre d’approche à cause de petits problèmes qui sont vite oubliés et dont les conséquences sont parfois l’échec pur et simple de l’approche.

L’analyse statique se heurte par exemple aux problématique des navigateurs et leurs interpréteurs dont la découverte des bug liés aux uses after free reste insoluble pour l’analyse statique. Parfois l’exemple de découverte de bug par une méthode d’analyse statique fonctionne parce-que la taille du code, sa complexité et l’absence d’allocation mémoire sur le tas (heap), etc…

L’auteur décrit en suite une vulnérabilité sur 60 lignes de code dans un cas très simple sans multithreading, etc… mais qui cependant n’est pas détecté par analyse statique. C’est du à des problèmes de sur-approximation d’un état.

HAVOC, par l’ajout d’annotation dans le code arrive à détecter ce type de vulnérabilités, mais comme il faut annoter le code, il ne s’agit pas réellement d’une analyse statique automatique, et aucune solution n’a été apportée pour l’instant.

Un autre cas d’échec ce sont les navigateurs avec les use-after-free. Il s’avère qu’il s’agit d’un problème difficile à résoudre, puisqu’il faut modéliser le tas (heap) et ses structures de données associées comme les listes chainées. Lorsqu’il y a un free sur un pointeur de la liste, on peut se retrouver avec un pointeur qui pointe n’importe ou. Le problème c’est que la vision abstraite de la liste est bien plus courte à cause de la sur-approximation, et donc au lieu d’avoir un seul élément de la liste taggué comme contenant un pointeur foireux, c’est l’ensemble des éléments de la liste qui sont considérés foireux, et donc on ne sait pas exactement ou se situe la faille.

(NDLR: là encore je vous encourage à regarder les actes !!!).

C’est pour ça que dans le contexte des navigateurs, google considère que le navigateur crashera et sera pwné, et qu’il le place dans une sandbox pour contenir l’attaque, plutôt que d’essayer de supprimer tous les bugs du parseur. Là encore javascript et sa complexité vient mettre la zone.

Coté analyse statique de binaires, les pointeurs entrainent forcément une sur-approximation qui vient compromettre la précision de l’analyse.

(NDLR: ça va un peu trop vite pour synthétiser les problèmes rencontrés pour chaque cas :/).

Comme le dit l’auteur, notre capacité à générer du code complexe surpasse notre capacité à le comprendre et à l’analyser.