Par contre, d'un point de vue sécurité, il n'y a pas eu que des approches « langage » pour réduire l'impact de ces bugs, il y a eu aussi des évolutions prenant des approches différentes, comme la mitigation de ces bugs au niveau OS.
Tout à fait tu peux même avoir une approche architecturale. Par exemple en séparant le code qui gère les IO du code plus critique ou en utilisant en langage plus sûr pour les IO et un langage plus orienté performance pour le code critique.
Mais il faut se rappeler qu'un buffer overflow, sur un OS prenant la sécurité au sérieux, c'est pas aussi facilement exploitable qu'il y a vingt ans.
Il faut voir ce que l'on appel exploitable. L'exécution de code arbitraire c'est rendu plus complexe par exemple avec les pages mémoires non exécutables, mais le simple fait de faire crasher un service peu déjà être une exploitation grave de la faille. Soit parce que tu ne veux pas que ce service tombe, soit parce que faire tomber ce service consomme une partie de tes ressources et donc le faire tomber en boucle peu consommer toutes tes ressources (tout ton CPU, tout ton espace disque, flooder tes alertes monitoring pour cacher une attaque plus sophistiquée,...).
Après, dans l'idéal, les deux approches sont complémentaires, mais certains langages safe ont tendance à faire leur propre gestion mémoire, souvent orientée performance et non sécurité (faisant l'hypothèse zéro bugs dans le compilo), donc certains bugs mémoire dans le compilo peuvent du coup être plus graves, car certaines mitigations ne s'appliquent plus.
Ça me fait penser (je vais avoir du mal à retrouver des pointeurs là dessus) que l'un des grands gap pour la performance mémoire actuellement semble être qu'on utilise une mémoire trop fiable. Si on change les prérequis mémoire, les constructeurs peuvent faire quelque chose de bien plus performant. Ça ajoute de la charge au code, mais ça reste plus efficace. Je crois que c'est dans un GLMF que j'avais lu ça.
[^] # Re: Performances vs. Sécurité
Posté par barmic 🦦 . En réponse au journal Le glissement du C++ (et dans une moindre mesure du C) vers une position indésirable. Évalué à 1.
Tout à fait tu peux même avoir une approche architecturale. Par exemple en séparant le code qui gère les IO du code plus critique ou en utilisant en langage plus sûr pour les IO et un langage plus orienté performance pour le code critique.
Il faut voir ce que l'on appel exploitable. L'exécution de code arbitraire c'est rendu plus complexe par exemple avec les pages mémoires non exécutables, mais le simple fait de faire crasher un service peu déjà être une exploitation grave de la faille. Soit parce que tu ne veux pas que ce service tombe, soit parce que faire tomber ce service consomme une partie de tes ressources et donc le faire tomber en boucle peu consommer toutes tes ressources (tout ton CPU, tout ton espace disque, flooder tes alertes monitoring pour cacher une attaque plus sophistiquée,...).
Ça me fait penser (je vais avoir du mal à retrouver des pointeurs là dessus) que l'un des grands gap pour la performance mémoire actuellement semble être qu'on utilise une mémoire trop fiable. Si on change les prérequis mémoire, les constructeurs peuvent faire quelque chose de bien plus performant. Ça ajoute de la charge au code, mais ça reste plus efficace. Je crois que c'est dans un GLMF que j'avais lu ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll