les pointeurs nuls ne causent pas de trous de sécurité en général. Un pointeur nul, c'est propre. ça segfaulte, et pouf. Libérer un pointeur null est ok avec la plupart des libcs, ça fait juste un no-op.
Les problèmes plus graves, sont par exemple les buffer overflows, où l'on va écrire trop long dans la mémoire (ie, 100 caractères dans un buffer fixe de 50) et donc écraser d'autres trucs. ça mène à un exploit si on peut écraser l'adresse de retour de la stack, en général. Les double-free() peuvent être assez méchants car eux aussi écrasent de la mémoire. Par exemple, on libère un pointeur vers une structure de 64 octets... On fait d'autres trucs, dont des allocations, qui pourront réutiliser ce bloc libéré...
Et après on ose cracher sur Java et sa gestion dynamique de la mémoire?
[^] # Re: Attention quand même
Posté par Olivier MARTIN . En réponse à la dépêche La robustesse de nombreux navigateurs web mise en cause. Évalué à 4.
Les problèmes plus graves, sont par exemple les buffer overflows, où l'on va écrire trop long dans la mémoire (ie, 100 caractères dans un buffer fixe de 50) et donc écraser d'autres trucs. ça mène à un exploit si on peut écraser l'adresse de retour de la stack, en général. Les double-free() peuvent être assez méchants car eux aussi écrasent de la mémoire. Par exemple, on libère un pointeur vers une structure de 64 octets... On fait d'autres trucs, dont des allocations, qui pourront réutiliser ce bloc libéré...
Et après on ose cracher sur Java et sa gestion dynamique de la mémoire?