Un virus sur deux utilise une faille aussi vieille que l’informatique elle-même ou presque : mentir à un programme sur la longueur des données qu’il doit traiter.“S’il n’a aucune instruction pour vérifier la validité de ce qu’il reçoit, le programme continuera à écrire et à traiter les données, quitte à effacer ses instructions originales”, explique Greg Morrissett, chercheur spécialiste des langages de programmation à l’université de Cornell. “Il devient ensuite très simple, pour un pirate, d’exécuter son propre programme dans la zone de mémoire qu’il a empruntée au programme défaillant.”
Un colmatage facile, en théorie
En théorie, cette erreur de programmation est particulièrement simple à corriger. Il suffit d’imposer une longueur limite aux données à recevoir. Mais cela fait bien vingt ans que l’on en parle et que le problème demeure. Au souci de limiter les vérifications pour accélérer la mise sur le marché du produit s’ajoute celui de l’évolution des langages de programmation eux-mêmes : “Le langage le plus utilisé à ce jour, C++, requiert une gestion manuelle de la mémoire, alors que Java, par exemple, se charge de tout automatiquement, en imposant un moteur intermédiaire d’interprétation du programme”, poursuit Greg Morrissett.
Des corrections par millions
C’est d’ailleurs de ce constat qu’est parti le chercheur pour mettre au point Cyclone, un nouveau type de moteur de traduction du code initial en langage machine. “Nous sommes face à un problème équivalent à celui du bogue de l’an 2000, affirme l’universitaire. Il n’est pas plus possible de réécrire tous les programmes existants dans un langage de nouvelle génération qu’il n’était réalisable de corriger les milliards de lignes de programmes utilisant un format de date incompatible avec l’an 2000.” Au lieu de réécrire le programme dans son intégralité, Cyclone se contente d’en faire l’analyse et d’y ajouter les instructions qui permettent de le sécuriser en utilisant les nouvelles techniques de gestion indirecte de la mémoire. “Nous ne sommes pas les seuls à avoir essayé”, reconnaît Greg Morrissett pour qui le principal problème reste de ne pas ralentir l’exécution du programme par trop d’instructions supplémentaires.Un souci qui ferait toute l’originalité de sa technique : “Nous avons mis au point un mécanisme de compensation qui restitue en grande partie les performances initiales du programme”, affirme le chercheur. Le projet, ouvert à tous les développeurs sur le principe du logiciel libre, n’est cependant pas prêt de pouvoir être transformé en produit commercialisable. Selon Greg Morrissett, les performances sont encore loin d’être convaincantes.
Vifs ou sûrs, il faut choisir
“Nous sommes confrontés au problème que rencontrent les nouveaux langages, explique-t-il. Ces derniers sont beaucoup plus sûrs, mais au prix d’une baisse très notable de la rapidité d’exécution et c’est justement cela que les programmeurs privilégient en général.”Pour le chercheur américain, il faudra sans doute compter encore une bonne dizaine d’années avant que des techniques de sécurisation des anciens programmes puissent devenir réellement exploitables. “Et il ne s’agit encore que d’une étape, avertit en conclusion Greg Morrissett. Sécuriser le moteur d’un programme n’est pas suffisant. Au final, il sera également nécessaire de gérer la façon dont il communique de façon sécurisée avec l’extérieur et sassurer que les données ne sont ni corrompues ni mensongères.”
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
