Il aura fallu le temps, mais les spécialistes se rendent enfin compte que la sécurisation du code applicatif est une tâche essentielle, car tout commence par là. Le problème est que l’on est démuni à la fois pour ce qui est des outils, mais surtout pour le cheminement intellectuel qui n’a pas été effectué par les développeurs, qui s’’intéressent aux fonctionnalités du code plus qu’à ses retombées sécuritaires.

C’est dans ce contexte qu’il faut placer une étude très sérieuse menée par Brendan Dolan-Gavitt, de l’Université de New York : « Chaff Bugs: Deterring Attackers by Making Software Buggier », qui préconise de truffer le code de vulnérabilité de manière à bloquer, pour le moins compliquer la tâche des hackers potentiels.

La méthode est pour le moins originale, qui consiste donc à prendre un code que l’on veut protéger et de le remplir d’un grand nombre de vulnérabilités, évidemment pas des erreurs de codage, mais bien des faiblesses sécuritaires, susceptibles de fragiliser le logiciel et de servir de points d’ancrage à une attaque. Des vulnérabilités qui vont servir de leurres.

Les auteurs de l’étude, qui ne manque pas d’originalité, font la distinction entre les faiblesses non fonctionnelles de celles, beaucoup plus dangereuses, qui sont liées au cœur de l’application et peuvent l’empêcher de se comporter normalement. Autrement dit, entre les failles qui vont se voir tout de suite, parce que l’application ne fonctionnera plus et celles qui n’auront pas d’incidence et que l’on pourra plus facilement masquer.

_{L’idée du groupe de chercheurs derrière l’initiative « Chaff Bugs » est de noyer le criminel potentiel par un déluge de fausses failles, censées lui faire perdre du temps…}

Danger…

A vrai dire, on ne souscrit pas à cette séparation des genres, car une faiblesse est une faiblesse et si vous injectez une extension susceptible d’exécuter un dépassement de mémoire tampon, elle n’est peut-être pas liée au « métier » de l’application, mais permettra néanmoins d’en prendre le contrôle et d’exécuter du code non invité, sauf si elle ne fait strictement rien.

L’idée sur laquelle ses fondent nos chercheurs, est de suivre le cheminement des criminels.

Dès lors qu’ils ont décidé de s’attaquer à une cible et selon qu’ils fonctionnent en aveugle ou vers une cible déterminée, ils cherchent à exploiter une faiblesse, qu’ils auront pris soin de détecter à l’avance.

Et la stratégie de Dolan-Gavitt est de leur proposer une cible dans laquelle il n’y a pas une faille, mais 500 ou 1000 failles différentes, placées « bien en évidence ». Le hacker se retrouvant alors dans la même situation qu’un cambrioleur devant une porte protégée par 250 serrures, dont une seule permet effectivement de l’ouvrir et qu’il lui faut trouver.

Partant du principe que ces gens-là « n’ont pas le temps », le fait de devoir tester un nombre important de combinaisons peut effectivement s’avérer décourageant. C’est en tout cas l’argument que mettent en avant les tenants du « chaff bug ». Sauf que les hackers disposent d’outils très sophistiqués d’analyse de failles et qu’ils sont parfaitement capables de détecter de manière automatique l’intérêt et la finalité d’une faille.

Il ne faut donc pas se faire trop d’illusions, d’autant que ce travail d’introspection de failles se fait souvent en parallèle, sans intervention des hackers et que ceux-ci ne seront pas perturbés s’ils doivent attendre quelque peu.

On peut ne pas être d’accord

Le principe est certes séduisant… mais il est très contestable.

D’abord, il ne faut pas prendre les hackers pour des imbéciles.

Ils auront tôt fait de comprendre la manœuvre et de s’y adapter. D’autant qu’ils trouveront dans le « dark web » des outils d’intelligence artificielle qui les aideront dans leur démarche.

Il nous paraît également difficile de garantir qu’une faille n’aura pas de conséquences sur l’application à protéger. Et le risque est élevé que sous couvert de protection, nous offrions sur un plateau, tous les ingrédients nécessaires aux hackers, pour effectuer leur sinistre « travail ».

La motivation des chercheurs, nous semble, enfin, sinon contestable, pour le moins ambigüe, qui nous proposent un outil d’injection de bogues à destination de programmes C et C++, avec des cibles bien précises de leurres portant sur des débordements de mémoire tampon et de « heap » pour les runtime d’exécution. Mais un outil qui ne s’applique qu’au binaire et donc inutilisable si l’on dispose des sources des applications, comme c’est le cas de l’Open Source.

Nous nous posons des questions, enfin, sur l’allure du logiciel protégé, ainsi bardé de plusieurs centaines de leurres, que les développeurs auront à maintenir et pour lequel ils devront faire la part entre ce qui procède du fonctionnel, de ce qui n’est qu’habillage de circonstance.

A vrai dire, nous pensons qu’il vaudrait mieux apprendre à coder proprement plutôt que de s’embarquer dans une voie que l’on peut juger incertaine…