Un bogue affecte les iPhone, un autre touche Windows et un troisième affecte les serveurs tournant sous Linux. À première vue, ces bogues n’ont rien en commun puisqu’ils concernent des plateformes différentes : Android, iOS, macOS, Windows, Linux. La réalité serait cependant toute autre à en croire Alex Gaynor, ingénieur en sécurité logicielle chez Mozilla précédemment en poste chez USDS (United States Digital Service).Lors de la troisième édition du « ;Weakest Link ;», le rendez-vous annuel organisé par Motherboard Vice sur le thème de l’avenir du piratage informatique et de la cybersécurité, Alex Gaynor a évoqué un problème sérieux qui, selon lui, menacerait Internet, mais qui semble paradoxalement laisser les développeurs complètement indifférents.
Gaynor a expliqué que les trois bogues évoqués précédemment existent parce que les logiciels qu’ils affectent sur les différentes plateformes ont été codés avec des langages de programmation qui ont la fâcheuse tendance de favoriser la survenue d’erreurs de type « ;memory unsafety ;», en autorisant l’accès aux régions invalides de la mémoire. Cette catégorie d’erreurs peut causer des bogues et des vulnérabilités de sécurité lors des procédures d’accès en mémoire.
En autorisant la survenue d’erreurs de type « ;memory unsafety ;», des langages de programmation tels que C et C++ auraient ainsi contribué à la dissémination d’un flux presque sans fin de failles de sécurité critiques pendant de nombreuses années. Comme exemple de ces vulnérabilités, on peut citer : les confusions de type, le dépassement de tampon, le dépassement de capacité d’entier et la vulnérabilité « ;use after free ;».
Les confusions de type peuvent survenir lorsqu’une portion de code ne vérifie pas le type d’objet qui lui est passé et l’utilise à l’aveuglette. Ce genre de situation peut s’avérer dangereuse dans la mesure où un type est exprimé comme une disposition dans l’implémentation de bas niveau d’un logiciel. De plus, avec les confusions de type, les mauvais pointeurs sur les fonctions ou les mauvaises données sont assignés à la mauvaise portion du code, ce qui peut dans certains cas conduire à une exécution du code.
Le dépassement de tampon (ou buffer overflow en anglais) est une faille de sécurité critique qui se produit lorsque l’utilisateur entre une chaine de caractères qui va se retrouver dans un tableau de caractères de taille insuffisante. Cela entraine l’écriture de données en dehors de la zone mémoire allouée pour le tableau. L’exploit HeartBleed, par exemple, qui a eu un impact sur 17 % des serveurs Web sécurisés sur Internet, était une vulnérabilité de dépassement de tampon permettant de lire 60 Ko après la fin d’une liste, y compris les mots de passe et autres données des utilisateurs.
Le dépassement de capacité d’entier, une faille difficile à détecter qui utilise le fait que les nombres ne peuvent dépasser une certaine valeur qui dépend du nombre de bits utilisés pour leur représentation et de leur méthode de codage.
La vulnérabilité « ;use after free ;» se présente, en général, dans le cas où on utilise un pointeur ou des données en mémoire, alors que le pointeur (ou le bloc mémoire) a déjà été libéré.
Ensemble, ces vulnérabilités représenteraient les exploits les plus fréquemment rencontrés dans des logiciels populaires tels que Firefox, Chrome, Windows, Android ou encore iOS. Gaynor en dénombre déjà au moins 400 et affirme : « ;Je suis les avis de sécurité pour ces projets depuis plus d’un an et, dans presque toutes les versions de ces produits, plus de la moitié des vulnérabilités sont de type memory unsafety. Plus troublant encore, les vulnérabilités sévères et critiques […] sont presque toujours de type memory unsafety ;».
Malgré les risques importants liés à la sécurité qu’ils font planer en permanence sur les logiciels qu’ils soutiennent, les langages de programmation « ;memory unsafety friendly ;» comme le C ou le C++ ont toujours la côte auprès des développeurs, alors que des alternatives éprouvées telles que Rust, Swift, pouvant être considérées comme des langages « ;memory safe ;» semblent à la traine.
Cette situation serait peut-être due au fait que, dans le cadre d’un nouveau projet, les développeurs ont tendance à opter pour un langage de programmation en fonction des langages que leur équipe connait, des performances et de l’écosystème de bibliothèques qui peuvent découler de ce choix. Le volet sécurité qu’implique ce choix n’est presque jamais considéré, ou du moins pas suffisamment, lors de la prise de décision estime Gaynor.
De plus, la plupart des projets logiciels, même les plus importants pour la sécurité d’Internet, ne sont pas nouveaux. Ils ont été lancés il y a une décennie ou plus. Linux, OpenSSL et le serveur Web Apache par exemple ont tous plus de vingt ans. Pour des projets d’envergure comme ceux-ci, réécrire tout le code dans un nouveau langage n’est pas une option. Ils ont besoin d’être transférés progressivement, ce qui implique que les projets devront être écrits et maintenus dans deux langages différents au lieu d’un seul. Cela suppose également qu’il faudra former une grosse équipe, ce qui prend beaucoup de temps et nécessite plus de moyens.
Le plus gros problème serait enfin lié au fait que beaucoup de développeurs ne croient pas du tout qu’il y a un problème. Ils ne croient pas que les langages comme C ou C++ facilitent ces vulnérabilités, mais que ce sont simplement d’autres ingénieurs qui écrivent du code bogué. Ils ne pensent pas qu’il y aurait un quelconque problème avec ces langages prétendument « ;memory unsafety friendly ;», car aucun code n’est parfait, mais simplement des personnes qui ne savent pas correctement les utiliser.
Source : Motherboard Vice
Et vous ?
Qu’en pensez-vous ? Quel est ou quels sont vos langages de prédilection ? Partagez-vous la théorie des langages « memory unsafety friendly » comme C ou C++ mise en avant dans cet article ? Expliquez votre point de vue. Êtes-vous d’accord avec Gaynor lorsqu’il déclare que le volet sécurité est trop souvent négligé au moment du choix d’un langage ?Voir aussi
Les pièges du C Google publie des détails sur une faille non corrigée d'IE et Microsoft Edge qui a été signalée en fin novembre C2 : un langage qui se présente comme une évolution de C plus rapide, sans fichiers d'en-tête, avec système de build intégré et d'autres changements Pourquoi les langages C et C++ auraient-ils encore de nombreuses années devant eux ? Donnez votre avis 
Envoyé par KsassPeuk
.
