Si vous vous intéressez un peu à la programmation et à l'actualité du moment à travers sites, forums ou magazines, vous êtes surement tombés début mars sur tout un tas d'articles suite à la publication par la NSA de sa liste des langages sûrs en matière de gestion mémoire.
Ce que vous n'avez peut-être pas lu, c'est que Delphi en fait partie.
Comme dans tout langage on peut faire n'importe quoi en Delphi mais entre le fonctionnement du langage Pascal, de sa gestion des objets en Object Pascal, de la librairie de gestion mémoire (FastMM) et des compilateurs efficaces fournis par Embarcadero, on se retrouve avec des exécutables robustes. On peut donc s'attendre à des programmes sans fuites mémoires et sans anomalies pouvant conduire aux failles de sécurité trouvées bien trop souvent ces dernières années dans des logiciels ou systèmes d'exploitation très (trop ?) répandus.
Ce n'est pas parce qu'on fait du Delphi (ou n'importe quel autre langage typé et compilé) qu'on fait forcément quelque chose de clean, mais si on utilise correctement les objets le résultat final est "propre".
Rappels de base :
- ce qu'on instancie ou alloue doit être libéré
- surveiller la consommation mémoire ou au minimum s'assurer que tout est bien libéré comme il se doit en fin de programme
- ce qui peut être attaché à un autre objet, lui-même géré proprement, doit l'être pour se simplifier la vie
- les violations d'accès et débordements de pile doivent être interceptés, traités et surtout éliminés une fois la cause identifiée !
Cela n'empêchera pas un attaquant de bidouiller des choses à partir de l'accès à la mémoire physique de l'ordinateur et son état courant, mais ça éliminera des sources de plantages liées à vos projets.
Bien entendu vous devez aussi limiter les dépendances incontrôlées de vos projets, vous assurer régulièrement que les projets / librairies / composants qui viennent d'ailleurs ont une conception adaptée à votre niveau d'exigence en matière de sécurité et de code propre. C'est parfois compliqué et chronophage, mais il en va de la sécurité de vos données, de celles de vos utilisateurs et clients, et de la pérennité de votre activité.
N'hésitez pas à utiliser des projets comme EurekaLog, Deleaker ou Mad Except (parmi de nombreux autres) dans vos projets en conception et débogage. Ils peuvent aussi parfois servir en production (notamment sur des cas non reproductibles chez vous) et qui ne peuvent se résoudre par débogage à distance via PAServer ou d'autres techniques.
Activez ReportMemoryLeaksOnShutdown dans vos projets, au moins en configuration de débogage (à éviter en production pour ne pas effrayer vos utilisateurs s'il y a des oublis de libération mémoire non traités dans leur version).
Si vous avez besoin de mettre vos idées au clair sur ces sujets référez vous à la documentation sur la gestion mémoire dans Delphi ou lisez des livres comme "Delphi memory management" ou "Delphi High Performance". Nous pouvons aussi en discuter à l'occasion d'une consultation sur vos projets ou une formation spécifique.
Je vous recommande également de lire ces deux articles en lien avec le sujet du moment et la fameuse liste des langages sûrs :
- Is Delphi A Memory Safe Language? de Marco Cantu
- Memory safety does not exist and we shouldn't pretend it does de Andrea Raimondi
