Je rêve d’un jour où la sécurité ne sera plus une option. J’ai donc commencé à mettre au point le modèle CDI [1] [2] : une architecture Harvard modifiée qui dédie un troisième espace d'adressage indépendant pour la pile de contrôle. Ce n'est pas la solution à tous les problèmes, mais ça y contribue beaucoup ! Pour preuve, un exploit récent divulgué à pwn2own [3] aurait facilement été stoppé par ce mécanisme. Mais cet exploit me sidère par son vecteur d'attaque que j’ignorais jusque-là : l'incontournable printf(3). Quand votre librairie standard inclut l’équivalent d’une machine de Turing, pour dynamiquement parser ou afficher du texte, ce n'est plus de l’idiosyncrasie mais de l'idiotie.
Le modèle CDI (sigle de Contrôle-Donnée-Instruction) empêche toute confusion entre les types essentiels, évitant d’utiliser des données en tant que pointeurs d’instructions (ou vice versa), et garantit l’intégrité de la pile de contrôle. Le développeur peut toujours saboter sa propre pile de données, mais cela n’affecte plus directement le chemin d’exécution du code. Le modèle CDI n’affranchit évidemment pas de contrôler toutes les autres bornes.
Une fois cette vulnérabilité inhérente enfin résolue, l'attention se porte maintenant sur les vecteurs qui en abusaient. Et si l’on prend la peine de creuser un tout petit peu, c’est une nouvelle foire aux horreurs qui se dévoile, car on trouve des structures et méthodes qui sont adoptées, acceptées, normalisées, enseignées depuis des décennies. Cela fait partie d'un tout, à prendre en entier ou à laisser. Le C, c’est comme ça.
1. Pourquoi en sommes-nous là ?
Bienvenue dans les coulisses de l…
- Accédez à tous les contenus de Connect en illimité
- Découvrez des listes de lecture et des contenus Premium
- Consultez les nouveaux articles en avant-première
