En fait si, ça existe déjà.
Des analyseurs statiques comme coverity avaient déjà détecté de tels bugs (déréférencement pointeur NULL), mais pas tous.
Ensuite, dans le cas évoqué, l'auteur du journal a oublié de préciser une chose. L'exploit utilisait un comportement de gcc très particulier : en analysant le flot du code, gcc voyait qu'on effectuait un check sur la nullité du pointeur _après_ l'avoir déréférencé (mais ce déréférencement n'était pas exploitable), et du coup supprimait (optimisait) la vérification du pointeur null, se disant qu'il ne pouvait pas l'être parce que s'il était null, on n'aurait pas pu le déréférencer (ou on aurait crashé). Du coup, l'éxécution se poursuivait alors que le code n'aurait _jamais_ dû être exécuté.
Brad a fait tout un foin de cette faille, mais ce n'est en rien une "nouveau type de faille". C'est juste un déréférencement du pointeur non initialisé, point barre.
[^] # Re: Analyseur statique...
Posté par neologix . En réponse au journal Un autre type de faille locale. Évalué à 8.
Des analyseurs statiques comme coverity avaient déjà détecté de tels bugs (déréférencement pointeur NULL), mais pas tous.
Ensuite, dans le cas évoqué, l'auteur du journal a oublié de préciser une chose. L'exploit utilisait un comportement de gcc très particulier : en analysant le flot du code, gcc voyait qu'on effectuait un check sur la nullité du pointeur _après_ l'avoir déréférencé (mais ce déréférencement n'était pas exploitable), et du coup supprimait (optimisait) la vérification du pointeur null, se disant qu'il ne pouvait pas l'être parce que s'il était null, on n'aurait pas pu le déréférencer (ou on aurait crashé). Du coup, l'éxécution se poursuivait alors que le code n'aurait _jamais_ dû être exécuté.
Brad a fait tout un foin de cette faille, mais ce n'est en rien une "nouveau type de faille". C'est juste un déréférencement du pointeur non initialisé, point barre.