L’étude et la compréhension des buffer overflow datent de 1972, et leurs premiers usages documentés de 1988 [1]. Près de 50 ans plus tard, où en sommes-nous ? Il nous faut bien admettre que la situation est déprimante : Microsoft et Google reconnaissent chacun ([2], [3]) que près de 2/3 des attaques utilisent à un moment ou un autre une vulnérabilité mémoire. Le ver Morris, qui n’était au départ qu’une preuve de concept, avait quand même coûté la bagatelle de quelques millions de dollars à l’époque… Aujourd’hui, les coûts sont abyssaux : sur le plan financier bien sûr, mais aussi pour nos vies privées, voire nos vies tout court. Face à ce problème, de nombreuses approches sont possibles : analyse statique du code, instrumentation et vérification à l’exécution, langages « sûrs »… Je vous propose d’explorer dans cet article un vieux concept remis au goût du jour, les capabilities, et tout ce qu’elles pourraient nous permettre de faire.
La sûreté mémoire désigne la protection de la mémoire contre des accès erronés (les bogues logiciels) ou frauduleux (vulnérabilité de sécurité) et peut être vue suivant deux axes :
- la sûreté spatiale concerne les problèmes liés aux buffer overflows et autres accès hors bornes ;
- la sûreté temporelle concerne les problèmes liés à la temporalité : use-after-free…
On peut blâmer avec justesse le C ou le C++ d’être des langages sans sûreté mémoire, mais ce sont ceux qui étaient disponibles en production à l’époque où les lignes de code de nos environnements ont été écrites. Réécrire toutes ces lignes dans un langage plus policé, Rust par exemple, est tout simplement impossible. Qui peut se lancer aujourd’hui dans l’aventure...
