Je n'ai pas du tout nie l'existence de grandes familles de bugs. D'ailleurs, mon journal detaille 3 grandes familles de bugs que j'ai rencontres.
Je n'ai pas non plus nie que certaines techniques puissent etre utiles pour pas mal de bugs dans une famille donnee.
Mais de la a dire qu'elles puissent eliminer toute la famille en question, la, c'est non.
Par exemple tu mentionnes les debordements de tampons ("buffer overflow"). Selon les cas, un bug de ce type peut:
- soit permettre l'execution de code arbitraire, auquel cas les bonnes vieilles techniques dites ASLR et DEP (liens dans mon journal) limitent les possibilites d'y parvenir mais pas a 100%, et le sandboxing limite les possibilites pour du tel code d'agir sur le reste du systeme mais comme il y a deja plein de choses a manger a l'interieur du sandbox, c'est pas forcement un probleme pour l'attaquant.
- soit permettre aux scripts d'acceder en lecture ou en ecriture a de la memoire arbitraire, auquel cas aucune des techniques mentionnees ci-dessus n'est utile!
- soit conduire a un bete plantage, ce qui est un cas de deni de service, et la non plus aucune des techniques envisagees n'est utile.
- etc, etc.
Dire que l'exemple 1 de mon journal peut etre corrige par une architecture plus solide, desole, mais ca n'a pas de sens. L'exemple 1, fuite d'information d'un domaine a un autre, est le type meme de ce qui est entierement hors de portee d'une solution generique, meme specifique aux structures de donnees du Web.
Edit: un petit rajout ici: Par exemple, l'attaque que j'ai mentionnee dans l'exemple 1 etait du type timing attack, une attaque par mesure du temps d'execution d'une operation. A part cette vulnerabilite a la mesure du temps, tout etait nickel et sans faille, mais cette attaque a tout fichu en l'air... et je suis bien certain qu'il n'y a pas de solution generique pour ca.
Pareil pour l'exemple 3, en fait. Deja l'exemple du script qui alloue trop de memoire, je ne vois pas quelle solution envisager pour ca. Tu peux compartimenter la memoire comme tu veux, le probleme est que tu as une ressource en quantite finie a partager entre tout le monde et que tu n'as pas de regle valable pour decider combien un script merite d'allouer pour lui-meme.
[^] # Re: Oui, mais
Posté par Benoit Jacob . En réponse à la dépêche Quelques aspects de la sécurité qui n'ont rien a voir avec le « Sandboxing ». Évalué à 7. Dernière modification le 22 janvier 2012 à 16:30.
Je n'ai pas du tout nie l'existence de grandes familles de bugs. D'ailleurs, mon journal detaille 3 grandes familles de bugs que j'ai rencontres.
Je n'ai pas non plus nie que certaines techniques puissent etre utiles pour pas mal de bugs dans une famille donnee.
Mais de la a dire qu'elles puissent eliminer toute la famille en question, la, c'est non.
Par exemple tu mentionnes les debordements de tampons ("buffer overflow"). Selon les cas, un bug de ce type peut:
- soit permettre l'execution de code arbitraire, auquel cas les bonnes vieilles techniques dites ASLR et DEP (liens dans mon journal) limitent les possibilites d'y parvenir mais pas a 100%, et le sandboxing limite les possibilites pour du tel code d'agir sur le reste du systeme mais comme il y a deja plein de choses a manger a l'interieur du sandbox, c'est pas forcement un probleme pour l'attaquant.
- soit permettre aux scripts d'acceder en lecture ou en ecriture a de la memoire arbitraire, auquel cas aucune des techniques mentionnees ci-dessus n'est utile!
- soit conduire a un bete plantage, ce qui est un cas de deni de service, et la non plus aucune des techniques envisagees n'est utile.
- etc, etc.
Dire que l'exemple 1 de mon journal peut etre corrige par une architecture plus solide, desole, mais ca n'a pas de sens. L'exemple 1, fuite d'information d'un domaine a un autre, est le type meme de ce qui est entierement hors de portee d'une solution generique, meme specifique aux structures de donnees du Web.
Edit: un petit rajout ici: Par exemple, l'attaque que j'ai mentionnee dans l'exemple 1 etait du type timing attack, une attaque par mesure du temps d'execution d'une operation. A part cette vulnerabilite a la mesure du temps, tout etait nickel et sans faille, mais cette attaque a tout fichu en l'air... et je suis bien certain qu'il n'y a pas de solution generique pour ca.
Pareil pour l'exemple 3, en fait. Deja l'exemple du script qui alloue trop de memoire, je ne vois pas quelle solution envisager pour ca. Tu peux compartimenter la memoire comme tu veux, le probleme est que tu as une ressource en quantite finie a partager entre tout le monde et que tu n'as pas de regle valable pour decider combien un script merite d'allouer pour lui-meme.