​LabVIEW comme langage de mémoire sécurisée

La sécurité de la mémoire fait référence à l'assurance qu'un programme accède à la mémoire d'une manière bien définie et prévisible. Cette fonctionnalité permet d'éviter la corruption, les fuites et l'écriture de données en dehors des limites prévues. Ces problèmes de mémoire peuvent provoquer des plantages et un comportement indéfini. Pire, les acteurs de la menace manipulent les problèmes de mémoire pour exécuter du code arbitraire, transformant les bugs de mémoire en vulnérabilités de sécurité importantes. Les préoccupations concernant la sécurité de la mémoire comprennent les types de problèmes suivants : 
 

• Débordements de buffer — Écriture en dehors des limites de la mémoire allouée. 
• Pointeurs pendus — Accès à la mémoire qui a déjà été libérée. 
• Utiliser-après-libre — Utilisation de pointeurs vers des emplacements de mémoire après qu'ils ont été libérés. 
• Fuite de mémoire — Impossible de libérer de la mémoire, ce qui entraîne un épuisement progressif des ressources. 

Les langages qui fournissent un accès direct à la mémoire (par exemple, en utilisant des pointeurs) sont particulièrement sensibles à ces problèmes. En revanche, les langages à mémoire sécurisée restreignent ou suppriment complètement la gestion directe de la mémoire par le développeur. 

Fondamentalement, LabVIEW est différent des langages textuels traditionnels. Son paradigme de programmation graphique est basé sur les principes de flux de données, où l'exécution du code est déterminée par le flux de données entre les nœuds (appelés instruments virtuels, ou VIs).

Les aspects suivants de l’architecture inhérente à LabVIEW favorisent la sécurité de la mémoire :

• Pas de manipulation directe des pointeurs — LabVIEW n'expose pas les adresses mémoire ou les pointeurs au développeur.
• Gestion automatique de mémoire : LabVIEW alloue et libère de la mémoire pour les variables, les tableaux et les structures selon les besoins.
• Sécurité de type — L'environnement LabVIEW impose une saisie forte à l'édition et à l'exécution.
• Valeurs de fil immuables — Une fois que les données entrent dans un fil de liaison (l'équivalent graphique d'une variable), elles ne peuvent pas être modifiées de manière inattendue ailleurs dans le programme.
• Comptage des références et collecte des déchets — LabVIEW gère la durée de vie des données, garantissant ainsi que la mémoire est automatiquement récupérée lorsqu'elle n'est plus utilisée.

Le paradigme du flux de données et son impact

Dans LabVIEW, les programmes sont construits en connectant des blocs fonctionnels avec des fils de liaison qui transportent des données. Chaque bloc ne s'exécute que lorsque toutes les entrées requises sont disponibles et que les emplacements des données ne sont pas accessibles avant la production des données, ce qui évite les situations de compétition de mémoire.

Figure 1. Exemple de code LabVIEW

Ce modèle évite naturellement de nombreuses erreurs de programmation dues au mauvais séquencement des opérations dans les langages impératifs.

Allocation et gestion de la mémoire

Le moteur d'exécution LabVIEW est responsable de toutes les allocations et désallocations de mémoire. Les développeurs n’ont jamais besoin de demander manuellement ou de libérer de la mémoire, éliminant ainsi le risque de fuites et d’erreurs d’utilisation après libération. Lorsque des tableaux ou des clusters (données de type structure) grossissent ou se réduisent, LabVIEW gère de manière transparente la mémoire associée. Par exemple, si un développeur crée une boucle qui constitue un tableau, LabVIEW redimensionne automatiquement le tableau et gère l'espace mémoire associé. Lorsque la variable tableau devient hors champ, le collecteur d’ordures de LabVIEW récupère la mémoire.

Saisie forte et vérification des limites

L'environnement de développement LabVIEW effectue une vérification de type rigoureuse lors de la compilation et de l'exécution du VI. Les tentatives de câblage de types de données incompatibles sont détectées à l'édition, ce qui évite les erreurs d'exécution. De plus, les opérations tableau et chaîne incluent la vérification des limites pour éviter les débordements de buffer.

Absence de contrôle de mémoire de bas niveau

L'une des garanties les plus efficaces est l'absence de contrôle de mémoire de bas niveau : LabVIEW ne fournit aucun mécanisme permettant à l'utilisateur d'effectuer un calcul de pointeur arbitraire ou d'accéder directement à la mémoire. Cette conception signifie que les vulnérabilités courantes en C ou en assembly, telles que les dépassements de pile ou de heap, ne sont pas possibles dans le code LabVIEW natif.

Pour mieux comprendre la sécurité de la mémoire LabVIEW, il est instructif de la comparer à des langages comme C, C++, et même Java ou Python.

• C/C++ — Ces langages fournissent un accès direct à la mémoire, nécessitent une gestion manuelle de la mémoire et sont sujets à de nombreuses erreurs de sécurité de la mémoire. CISA recommande de ne pas utiliser C/C++ pour de nouveaux projets.
• Java/Python — Ces langages fournissent une gestion automatique de la mémoire, mais permettent encore certaines erreurs de mémoire indirectes. Par exemple, de nombreux modules Python sous-jacents sont écrits en C, et des bugs dans ces modules peuvent entraîner des problèmes de mémoire dans l’application Python. Python n’applique pas non plus les règles de sécurité de la mémoire à l’exécution comme le font les autres vrais MSL.
• LabVIEW — LabVIEW ne fournit pas de pointeurs et utilise une saisie stricte, avec une mémoire entièrement gérée, réduisant considérablement la surface d'attaque et le risque d'erreurs. LabVIEW autorise l'utilisateur à appeler des DLL écrites en C/C++, ce qui peut introduire des problèmes de mémoire.

En résumé, la conception de LabVIEW élimine des catégories entières de vulnérabilités liées à la mémoire (par exemple, les débordements de buffer) et simplifie le développement sécurisé d’applications, offrant un avantage significatif par rapport aux langages traditionnels comme C et C++., avec une protection similaire à Python et Java.

La sécurité de la mémoire dans LabVIEW présente des avantages tangibles pour les développeurs, les organisations et les utilisateurs finaux :

• Risque réduit de vulnérabilités de sécurité — L'élimination des débordements de buffer et de l'utilisation abusive de pointeurs empêche de nombreux vecteurs d'attaque courants.
• Fiabilité plus élevée — Les applications risquent moins de planter en raison d'erreurs de mémoire difficiles à trouver.
• Développement plus rapide : les développeurs peuvent se concentrer sur la logique de l'application sans se soucier des bugs d'allocation ou de désallocation de mémoire.
• Maintenance facilitée : le code LabVIEW est moins sujet aux erreurs subtiles de bas niveau qui peuvent rendre la mise au point et la maintenance coûteuses et longues.
• Applications critiques pour la sécurité — Souvent, LabVIEW est utilisé dans des environnements où la fiabilité est primordiale, tels que l'automatisation en laboratoire, le contrôle industriel et la recherche scientifique.

Les débordements de buffer traditionnels se produisent lorsque les données dépassent les limites d'un buffer de longueur fixe, écrasant la mémoire adjacente et pouvant permettre l'exécution de code arbitraire. Dans LabVIEW, les opérations sur les tableaux et les chaînes sont toujours vérifiées aux limites. Les tentatives d'écriture au-delà de la fin d'un tableau ou d'une chaîne entraîneront une erreur d'exécution plutôt qu'une corruption silencieuse de la mémoire.

Comme tout environnement à mémoire sécurisée, il est important de comprendre les limites de LabVIEW :

• Intégration de code externe — L'appel de bibliothèques externes (DLL, bibliothèques partagées) de LabVIEW avec la fonction Appeler une fonction d'une DLL peut introduire des problèmes de sécurité de la mémoire si ces bibliothèques ne sont pas elles-mêmes sûres.
• Épuisement des ressources — Des boucles infinies ou une allocation de mémoire incontrôlée peuvent toujours entraîner un épuisement de la mémoire, mais pas une corruption.
• Compatibilité des versions — À mesure que LabVIEW évolue, certains comportements (par exemple, les optimisations de la gestion de la mémoire) peuvent changer, nécessitant une attention lors de la mise à niveau ou du portage de l'ancien code.

Pour maximiser la sécurité lors des appels de code externe, suivez ces bonnes pratiques :

• Isoler le code dangereux — Encapsuler les appels de bibliothèque dangereux dans un module ou un processus distinct. Utilisez des microservices ou IPC (communication entre processus) pour isoler le code à risque de mémoire. De cette façon, un plantage ou une corruption de la mémoire dans le code dangereux ne met pas toute l’application hors service.
• Valider rigoureusement les entrées et sorties — La corruption de la mémoire provient souvent de mauvaises entrées ou de sorties inattendues. Validez toutes les données transmises à la bibliothèque non sécurisée. Utilisez la vérification des limites, les vérifications NULL et les assertions de type.
• Employ Static and Dynamic Analysis Tools — Utilisez des outils pour détecter précocement les problèmes de mémoire. Utilisez les outils de mémoire statique et dynamique de LabVIEW, inclus avec LabVIEW Édition professionnelle, pour tester les problèmes de mémoire.
• Minimiser la surface dangereuse — N'exposez que les fonctionnalités minimales nécessaires de la bibliothèque dangereuse. Évitez de passer des structures de données ou des pointeurs complexes, sauf si c'est absolument nécessaire. Gardez l'interface aussi simple et bien définie que possible.
• Audit and Monitor — Audite régulièrement le code externe appelé par le programme LabVIEW. 

La conception de LabVIEW, basée sur un paradigme de flux de données graphique, une vérification de type forte, une gestion automatique de la mémoire et l’absence de manipulation directe des pointeurs, fournit un environnement hautement sécurisé en mémoire. Les développeurs bénéficient d’un risque réduit de bugs liés à la mémoire, d’une productivité accrue et de la possibilité de créer des applications pour des industries exigeantes et critiques pour la sécurité en toute confiance.

Bien qu'aucun environnement ne soit entièrement à l'abri des erreurs, en particulier lorsqu'il interagit avec des composants externes dangereux, LabVIEW place nettement plus haut la barre de la sécurité de la mémoire par rapport aux langages textuels traditionnels. Pour les organisations à la recherche de fiabilité et de sécurité dans les applications de mesure, d'automatisation et de contrôle, LabVIEW est un choix convaincant pour le développement en mémoire sécurisée.

• En savoir plus sur LabVIEW
• Comparer les éditions LabVIEW
• Demander une démo LabVIEW