On a pas mal entendu parler de HeartBleed, de WannaCry, de fuites de données confidentielles, de bugs d’iPhone ou d’Android coûtant des millions de dollars. Ces bugs ont tous un point commun.

Sécurité mémoire

J’ai récemment lu un article décrivant les causes de ces failles ayant coûté des millions à des entreprises comme Intel, Apple, Google, Facebook et j’en passe : elles sont toutes dues à des bugs de sécurité mémoire.

Je vais paraphraser un peu l’article pour expliquer ce qu’est cette catégorie de bug et quelle est la racine du mal. L’exemple pris dans l’article est celui d’un programme qui s’occupe d’une liste de dix éléments. Que se passe-t-il si on lui demande de nous donner le onzième élément ? La logique nous dicte que c’est une erreur et que le programme devrait nous le dire. En réalité, avec les langages sans gestion sécurisée de la mémoire, on va avoir un comportement indéfini. Parfois, le programme plantera, mais le plus souvent, il lira dans la mémoire l’endroit où le onzième élément devrait être et nous le donner. Le truc, c’est que les aléas d’exécution du programme peuvent faire qu’à cet endroit de la mémoire se trouvent des informations confidentielles, du genre mots de passe, numéros de cartes de paiement ou toute autre information que le programme manipule en temps normal, mais qui n’a aucun rapport avec notre liste. C’est ce qu’on appelle une vulnérabilité par dépassement de tampon (buffer overflow). C’est ce genre de faille qui a été mise en œuvre dans l’affaire HeartBleed qui, selon l’article, a touché 17% des serveurs web dans le monde.

Il existe d’autres attaques basées sur la vulnérabilité mémoire :

• mélange de types ;
• utilisation après libération de mémoire ;
• utilisation de mémoire non initialisée.

Mais je ne vais pas m’étendre dessus, vous avez compris l’idée. L’auteur de l’article semble être un spécialiste en sécurité vu qu’il est en charge du sujet au sein de Mozilla, et il affirme que plus de la moitié des failles de sécurité qu’il a détectées pendant plus d’un an d’études étaient dues à des faiblesses mémoire. Pire, les failles les plus critiques étaient quasiment toutes dues à une faute mémoire.

Causes

L’article se penche ensuite sur les causes de cette situation désastreuse. En effet, il existe des langages qui disposent des outils pour prévenir ce genre de faiblesse. Go, Swift et bien sûr Rust sont des exemples parmi d’autres. Pourtant, C/C++ dominent largement la base de code existante.

Cet état de fait est dû principalement à leur âge. Ces deux langages existent depuis plusieurs dizaines d’années alors que Rust a atteint sa version 1.0 en 2015. Mécaniquement, il y a plus de code C/C++ que de code Rust.

Oui, un jeu de mots bien pourri :p

Cela dit, un facteur aggravant vient s’ajouter : beaucoup pensent que le langage n’est pas un problème, il « suffit de ne pas créer de bugs » et donc de devenir meilleur. Ce n’est pas tout à fait faux, mais le niveau d’excellence à atteindre pour réussir à écrire du code dénué de failles mémoire dans un système complexe relève du divin. C’est humainement impossible, tout simplement. Le meilleur des meilleurs peut être fatigué, malade, avoir un moment d’inattention sur la mauvaise fonction du code… Et les faits corroborent cette hypothèse : on est plombés de failles et il ne se passe pas un an sans un scandale de fuite de données confidentielles.

Solutions

Maintenant qu’il est prouvé que la stratégie du « devenez meilleur et ne créez plus de bugs » ne fonctionne pas, on pourrait peut-être passer à une stratégie qui a une chance de réussir ? L’auteur présente rapidement Rust et suggère des points de communication pour convaincre les développeurs et les décideurs d’adopter ce genre de technologie. Le plus important à mes yeux est de développer une culture de la sécurité. Typiquement, le dépassement de tampon est enseigné à l’école comme étant une cause de crash. Mais il est rarement fait mention que selon le compilateur ou d’autres facteurs, ça peut rapidement devenir une faille critique de sécurité.

Pour lui, cet enseignement pourrait changer notre approche des failles de sécurité : non plus une par une comme pour un bug, mais plutôt comme un problème de fond dans le domaine de la programmation et des outils qu’on utilise pour coder, dont le langage de programmation lui-même.

Obstacles

L’article finit sur cette note positive, mais la réalité, à mes yeux, est bien plus sombre : il ne prend pas en compte l’immobilisme qui peut caractériser les grosses entreprises.

Je ne parle pas des boîtes qui sont dans l’air du temps, comme DropBox, Facebook, Google… mais des grosses entreprises qui accusent leur âge. Dans ces structures, l’inertie est telle que la moindre migration de technologie prend littéralement 3 ou 4 ans à s’accomplir. Des technologies qui ont moins de 10 ans ne sont même pas connues ne serait-ce que de nom. Il n’y a guère que les méthodes de management/communication qui évoluent vite (Scrum, par exemple). Oui, pour le bullshitware, il y a du monde, ça donne un coup de peinture à la façade et permet de dire aux candidats qu’on est modernes.

Mais quand il s’agit d’attaquer le cœur de la technologie, les décideurs ne veulent même pas en entendre parler. Ils ne voient que le coût (formation et adaptation des équipes) à court terme sans voir les gains à moyen ou long terme. Pire, même les ingénieurs ne sont pas plus motivés que ça, complètement anesthésiés par des années d’inertie et de déception vis-à-vis des décisions de leurs supérieurs.

Venir à bout de ces failles mémoire et de sécurité à la racine est possible, mais cela va prendre plusieurs générations, et je parle bien en termes de générations humaines. Dans un monde envahi par la technologie, se dire que le code qui la pilote est sûrement truffé de failles qui ne demandent qu’à être exploitées fait froid dans le dos.