Discussion :

[Hinault Romaric]

Les compilateurs pourraient être à l’origine des vulnérabilités de certaines applications
le MIT remet en cause la gestion du code instable

Le compilateur, l’outil de base dont ne peut se passer un développeur, pourrait être la cause des vulnérabilités de certaines applications. C’est en tout cas ce que concluent de nouvelles recherches qui ont été dévoilées par le MIT.

Menées par quatre chercheurs en informatique du laboratoire d’intelligence artificielle de la prestigieuse institution, les recherches révèlent que pour optimiser le code, les compilateurs peuvent supprimer certaines portions du code, pouvant conduire à la génération d’une application plus vulnérable.

Les chercheurs se sont penchés essentiellement sur l’optimisation du code instable, qui est en quelque sorte le traitement du code qui peut se comporter de façon imprévisible. Il s’agit par exemple de la division par zéro, le déréférencement d’un pointeur NULL, les dépassements de tampon, etc.

Pour ces cas de figure, plusieurs éditeurs de compilateurs ont choisi de supprimer complètement les portions de code pouvant entrainer un comportement imprévisible, lors de la transformation du langage source en langage machine. Cette pratique pourrait conduire à des vulnérabilités si le code en question contient des contrôles de sécurité, d’après les chercheurs du MIT.

Ceux-ci ont mené une étude sur plus d’une douzaine de compilateurs C/C++ pour voir leur comportement face au code pouvant entrainer un comportement imprévisible. Ils ont constaté qu’au fil du temps, ces compilateurs sont de plus en plus agressifs dans la façon de traiter un tel code, à cause des optimisations apportées à celui-ci. « Nous prévoyons une augmentation des bogues dus au code instable », concluent les chercheurs.

Ils ne se sont pas arrêtés là, et ont développé un correcteur statique pour les bouts de code identifiés comme instables. Baptisé STACK, leur correcteur fonctionne uniquement pour le code écrit en C/C++. D’après la description de STACK, il permet de détecter et avertir le programmeur lorsqu’il découvre un code instable dans son application, afin que celui-ci puisse corriger le problème au lieu de laisser le compilateur ignorer cette portion de code.

Les résultats des tests de STACK sur quelques programmes open source populaires sont impressionnants. Il a trouvé 160 problèmes dans les applications testées, y compris le noyau Linux (32 problèmes identifiés), PostgreSQL (9) et Python (5). Sur les 8 575 paquets de l’archive Debian Wheezy qui contenaient du code C/C++, STACK a détecté un code instable dans 3 471 paquets.

STACK est téléchargeable gratuitement sur GitHub.

Télécharger STACK sur GitHub


Source : les résultats de l’étude au format PDF


Et vous ?

Que pensez-vous de cette conclusion des chercheurs du MIT ?

Avez-vous testé STACK ? Si oui, a-t-il signalé des problèmes dans votre code ?

[germinolegrand]

-pedantic, c'est la base.

[Neckara]

Bonjour,

-pedantic, c'est la base.

Je ne suis pas vraiment d'accord, si on met -pedantic, tu te restreint au C89 . -pedantic est trop restrictif, pour moi il est obsolète. La "base", serait plutôt -Wall et -Wextra.

Sinon je trouve assez étrange que le compilateur supprime des portions de codes conduisant à un résultat indéterminé . J'aimerais bien savoir s'ils auraient pas passé des options du style -O2 à gcc pour leurs tests.

[germinolegrand]

D'un autre côté faut savoir se servir de -std=, évidemment que c'est -pedantic avec le standard que tu as demandé à ton compilo...

[Lynix]

Je ne suis pas vraiment d'accord, si on met -pedantic, tu te restreint au C89 . -pedantic est trop restrictif, pour moi il est obsolète. La "base", serait plutôt -Wall et -Wextra.

-pedantic fait en sorte que GCC n'active pas ses extensions, mais ça ne force pas pour autant le C89 (C'est juste la version par défaut)

Utilise -pedantic et -std=c11 et ça fonctionnera tout aussi

Par contre il est certain que -Wall et -Wextra au moins devraient être utilisés par n'importe quel utilisateur de GCC.

[ElTotor]

Il y a quelques temps, j'avais vu une faille du noyau linux qui correspondait exactement à cela ! Les détails sur http://lwn.net/Articles/342330/ (en anglais).

En gros, dans une fonction, un test était fait sur un pointeur pour savoir s'il était null ou non, et renvoyer une erreur si c'était le cas.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
    {
	struct tun_file *tfile = file->private_data;
	struct tun_struct *tun = __tun_get(tfile);
	struct sock *sk = tun->sk;
	unsigned int mask = 0;

	if (!tun)
	    return POLLERR;

Un patch a rajouté une ligne de code avant ce test et dans cette ligne, le pointeur était déréférencé. GCC, avec l'option de compilation qui va bien, a donc tout simplement supprimé le test, car pour lui, le déréférencement du pointeur devait obligatoirement provoquer une erreur. Manque de bol, dans certains cas, l'accès à la zone mémoire à l'adresse 0x0 pouvait être valide et ne pas générer d'interruption !

[Bktero]

Pour info, le site de STACK : http://css.csail.mit.edu/stack/

Ils donnent d'ailleurs un lien vers un excellent article (en anglais) expliquant la situation : http://web.mit.edu/newsoffice/2013/s...card-1016.html

Je trouve le titre un peu aguicheur, prenant un sérieux raccourci. Je pardonne l'équipe Actualités, il faut savoir être vendeur ^^ En fait, la "suppression" de code est un des choix faits par certains compilateurs pour gérer les undefined behaviours. Par définition même, les compilateurs peuvent faire ce qu'ils ont envie quand ils rencontrent un tel code, y compris purement et simplement supprimer le code. Le problème ne vient donc pas uniquement des compilateurs mais aussi des développeurs qui utilisent des codes non prédictibles. STACK, d'après ce que j'ai lu, possède une liste de tous les comportements indéterminés donnée par les normes C. Lors de l'analyse, il regarde le code source et si des comportements indéterminés sont utilisés. Il est aussi capable de trouver les blocs de code morts. En comparant le code présent après avoir enlever le code mort et celui après optimisation, il peut faire un delta et trouver ce que les compilateurs ont enlevé par des optimisations "malheureuses".

Je n'ai pas encore testé l'outil mais je trouve le principe très intéressant. On se repose beaucoup sur nos compilateurs pour optimiser nos codes et nous avertir d'erreurs potentiels. C'est normal mais cela ne devrait pas nous dispenser de pleinement maîtriser le code qu'on écrit et d'éviter au maximum les cas "aux limites".

[MacDev]

Que pensez-vous de cette conclusion des chercheurs du MIT ?

A mon avis, ils ont effectué un travail louable. ça fait un bon moment que je ne développe pas en C/C++. Mais à voir les explications, ça me parait logique.

[gangsoleil]

Je n'ai pas encore testé l'outil mais je trouve le principe très intéressant.

Trouvant moi aussi l'idee tres tres interessante, j'ai essaye de tester : c'est la croix et la banniere si tu n'as pas le tout dernier environnement a la mode avec pleins de trucs en plus...

C'est tout de meme tres - trop - souvent le probleme avec les projets de ce type : ca n'est fonctionnel que dans certains environnements sympathiques, et pour les autres, bah...