Dans le cadre de notre initiative Security project for QGIS, nous avions identifié un lot intitulé Improve Memory Safety, que l’on pourrait traduire approximativement par Amélioration de la sécurité mémoire.
Aprés avoir travaillé sur ce sujet ces derniers mois, voici un condensé de la problématique et de ce qui a été réalisé jusque là.
Présenter ce sujet n’est pas forcément chose aisée. Je m’efforcerai tant que possible de ne pas entrer dans des détails trop techniques pour me concentrer sur les enjeux de la démarche.
Il était une fois, aux États-unis…
En Novembre 2022, la NSA publie un rapport sur la sécurité des logiciels dans lequel elle écrit :
Microsoft and Google have each stated that software memory safety issues are behind around 70 percent of their vulnerabilities. Poor memory management can lead to technical issues as well, such as incorrect program results, degradation of the program’s performance over time, and program crashes.
Soit : 70% des vulnérabilités des logiciels viennent de problèmes de gestion de la mémoire
NSA recommends that organizations use memory safe languages when possible and bolster protection through code-hardening defenses such as compiler options, tool options, and operating system configurations.
La NSA recommande d’utiliser des MSL (Memory Safe Languages) ou de “durcir le code”. QGIS représente approximativement 1,5 millions de lignes de code de C++, language non-memory safe par défaut. J’opte donc pour l’option “durcir le code” plutôt que la reécriture qui aurait, il est vrai, eu l’avantage de me donner du travail jusqu’à la retraite.
C’est quoi le problème
Le C++ n’est pas un language “Memory Safe” par défaut, car il n’oblige pas à détailler le cycle de vie des morceaux de mémoire qu’il utilise.
Vous n’avez rien compris à cette phrase, pas grave, ça ne gène pas la compréhension de ce qui va suivre
Le développeur C++ est supposé faire attention, il ne doit pas oublier de supprimer un morceau de mémoire précédemment créé et éviter de le supprimer plusieurs fois, au risque respectivement, de voire le programme gonfler en mémoire ou crasher.
Ces problèmes de gestion de la mémoire peuvent être utilisés par des personnes malveillantes pour injecter du code dans un programme et récupérer des mots de passe ou des accès.
Une personne malveillante
Travail réalisé
Heureusement, le C++ propose des structures de contrôles, les smart pointers qui permettent de gérer le cycle de vie de la mémoire. Son utilisation permet d’éviter les fuites mémoires, les crashs et limite la surface d’attaque.
QGIS les utilise encore assez peu. L’idée est donc de répandre leur utilisation dans le code et d’empêcher l’ajout de code qui ne les utiliserait pas.
Pour cela j’ai développé un programme qui réécrit le code afin qu’il utilise des smart pointers, et j’ai ensuite passé beaucoup de temps de relecture pour éviter l’introduction de nouvelles erreurs.
Un contributeur QGIS en plein relecture de Pull Request
Pourquoi ne pas utiliser de l’IA ?
Il est difficile aujourd’hui de parler d’un sujet d’ingénierie logicielle sans parler d’IA (l’avantage est qu’on entend plus parler de blockchain) donc je me dois de répondre à la question “Est-ce qu’on aurait pu utiliser de l’IA pour cette tâche?” (ou “booster à l’IA” qui sont, il me semble, les termes consacrés chez les tech-bros).
Et la réponse est OUI. Mais NON. Déjà d’une part, parce-que le projet QGIS cherche encore quelle politique adopter vis à vis de l’IA et que celle-ci est pour l’instant soumise à un moratoire qui interdit son utilisation dans le core de QGIS.
D’autre part, cela aurait nécessité une relecture plus approfondie. En effet, mon programme de migration est déterministe : quand il se trompe, il se trompe toujours de la même manière. Difficile d’en dire autant d’une machine probabiliste.
Et donc c’est bon, on est memory safe ?
Non, un jalon a été franchi, mais il en reste d’autres. Ce travail va continuer dans les mois à venir.
En parallèle, j’ai aussi démarré un sujet similaire grâce à une grant QGIS.org. Elle vise à remplacer les annotations SIP_FACTORY par des unique pointers. Mais vous expliquer ce sujet ferait fuir les derniers lecteurs parvenus jusqu’ici.
Cette initiative s’inscrit dans une démarche plus large car nous pensons que toutes les problématiques en lien avec la sécurité doivent être adressées en même temps et avec la même intensité. A quoi bon installer une porte d’entrée blindée si on laisse la porte du garage ouverte.
À suivre …
Nous souhaitons nous inscrire dans une démarche d’amélioration continue du code et des processus de contribution et de distribution du logiciel QGIS. Il est à noter que cette initiative ne concerne pas que la sécurité, elle permet aussi de limiter les crashs ou l’empreinte mémoire du logiciel.
Elle a besoin d’un soutien financier. Si vous souhaitez, vous aussi, contribuer ou pour tout autres questions concernant QGIS n’hésitez pas à nous contacter à mailto:infos+qgis@oslandia.com.
Vous pouvez rester informé/e grâce à notre newsletter et nous suivre sur Linkedin.
