<i>Même si tu as un buffer overflow, il faut passer par dessus la protection nx, par dessus la randomisation d'adresse, voir les protections par canary. C'est déjà une autre pair de manche.</i>
Si on se place dans le cas d'un auteur/contributeur malveillant, c'est un jeu d'enfant de faire du code dont on sait d'avance ou l'erreur va tomber, comment le buffer overflow va déborder etc. Et c'est particulièrement pernicieux à trouver. Passé deux out trois niveaux d'indirections et quelques changement de format plus tard (its a long long way to tipperary) qui va aller vérifier que ton tableau fait bien N éléments et pas N-1.
Tu peux même pousser le vice jusqu'à coder un canary à la fin du tableau ... de N éléments.
Si quelqu'un te choppe (très très peu probable, mais pourquoi pas) tu peux toujours plaider non coupable, la faute d'inattention qui t'a fait sauter un élément, dans un tableau alloué quatre pages de code plus haut (voire dans un include, d'include).
Après il suffit que le débordement aille gentiment écraser l'élément suivant dans une structure (tu sais ou ça tombe) et plaf un pointeur de fonction/une addresse de retour qui part aux fraises.
Pour finir tu envois un packet/fichier/flux avec un élément de trop au bon endroit et le malware s'active sans que personne ne puisse le voir à moins d'une analyse poussée du code.
NX ne verra rien, pointeur de fonction ou pointeur tout court, si on retourne bien dans la zone d’exécution (si tant est qu'on l'ai quittée) on aura son feu vert.
La randomisation d'adresse tombe à plat puis que je corromps des données allouées au sein de la même structure.
Et le canary posé posé en fin de structure ne sera même pas chatouillé par une corruption qui se produit trop en aval.
Et là c'est un exemple de méthode parmi des centaines qui passent largement au dessus des protections génériques et qui sont quasiment insensibles au fuzzing.
Un mec qui décide de créer une faille exprès dans son code, il a largement les moyens de la planquer tranquillement et de l'activer à la demande. Les techniques mentionnées marchent principalement contre les méchants qui essayent d'abuser un code écrit honnêtement.
[^] # Re: Solution libre
Posté par Jerome Herman . En réponse au journal Avec Android, vous en avez plus pour votre argent. Évalué à 7.
<i>Même si tu as un buffer overflow, il faut passer par dessus la protection nx, par dessus la randomisation d'adresse, voir les protections par canary. C'est déjà une autre pair de manche.</i>
Si on se place dans le cas d'un auteur/contributeur malveillant, c'est un jeu d'enfant de faire du code dont on sait d'avance ou l'erreur va tomber, comment le buffer overflow va déborder etc. Et c'est particulièrement pernicieux à trouver. Passé deux out trois niveaux d'indirections et quelques changement de format plus tard (its a long long way to tipperary) qui va aller vérifier que ton tableau fait bien N éléments et pas N-1. Tu peux même pousser le vice jusqu'à coder un canary à la fin du tableau ... de N éléments.
Si quelqu'un te choppe (très très peu probable, mais pourquoi pas) tu peux toujours plaider non coupable, la faute d'inattention qui t'a fait sauter un élément, dans un tableau alloué quatre pages de code plus haut (voire dans un include, d'include). Après il suffit que le débordement aille gentiment écraser l'élément suivant dans une structure (tu sais ou ça tombe) et plaf un pointeur de fonction/une addresse de retour qui part aux fraises.
Pour finir tu envois un packet/fichier/flux avec un élément de trop au bon endroit et le malware s'active sans que personne ne puisse le voir à moins d'une analyse poussée du code.
NX ne verra rien, pointeur de fonction ou pointeur tout court, si on retourne bien dans la zone d’exécution (si tant est qu'on l'ai quittée) on aura son feu vert. La randomisation d'adresse tombe à plat puis que je corromps des données allouées au sein de la même structure. Et le canary posé posé en fin de structure ne sera même pas chatouillé par une corruption qui se produit trop en aval.
Et là c'est un exemple de méthode parmi des centaines qui passent largement au dessus des protections génériques et qui sont quasiment insensibles au fuzzing.
Un mec qui décide de créer une faille exprès dans son code, il a largement les moyens de la planquer tranquillement et de l'activer à la demande. Les techniques mentionnées marchent principalement contre les méchants qui essayent d'abuser un code écrit honnêtement.