on est mi-2006. je trouve inadmissible qu'ils en soient encore à plâtrer leur parseur pour éviter qu'un bloc de ÄÄÄÄÄÄ mal placé fasse planter leur petit monstre ou pire permette une exploitation de code en local.
je sais pas, moi, "vérifier ses entrées", c'est un peu la base, non ?
dans le même style, la technique dite du fuzzing est connue depuis des lustres. je comprends qu'ils n'aient pas forcément pensé à s'en servir au tout début pour valider ledit parseur (et en fait, idem pour OpenOffice) mais une fois que le sujet est redevenu d'actualité l'an dernier, il fallait s'y coller et valider ce parseur. c'est un vecteur d'attaque, il faudra s'y coller tôt ou tard.
oh, et puis il y a ça : Schroepfer also predicts that security will continue to be a problem "for anything written in native code," such as C and C++. For example, he notes that security problems caused by memory issues have evolved over the years; from stack-based exploits, to heap-based, to null pointer exploits puisque tu as eu du mal à trouver. quelqu'un qui fait ou laisse passer ce type d'erreurs est un mauvais programmeur C. se planter de 1 en parcourant un tableau ou une liste est encore compréhensible à mes yeux, le reste ne devrait pas pouvoir résister à une revue de code sérieuse.
(disclaimer : je programme professionnellement en C.)
l'innovation se trouve actuellement dans les extensions, je trouve, et elle, elle m'épate vraiment.
[^] # Re: Vu aussi sur MozillaZine-fr
Posté par Gniarf . En réponse au journal Firefox avec Real ?. Évalué à 1.
je sais pas, moi, "vérifier ses entrées", c'est un peu la base, non ?
dans le même style, la technique dite du fuzzing est connue depuis des lustres. je comprends qu'ils n'aient pas forcément pensé à s'en servir au tout début pour valider ledit parseur (et en fait, idem pour OpenOffice) mais une fois que le sujet est redevenu d'actualité l'an dernier, il fallait s'y coller et valider ce parseur. c'est un vecteur d'attaque, il faudra s'y coller tôt ou tard.
oh, et puis il y a ça : Schroepfer also predicts that security will continue to be a problem "for anything written in native code," such as C and C++. For example, he notes that security problems caused by memory issues have evolved over the years; from stack-based exploits, to heap-based, to null pointer exploits puisque tu as eu du mal à trouver. quelqu'un qui fait ou laisse passer ce type d'erreurs est un mauvais programmeur C. se planter de 1 en parcourant un tableau ou une liste est encore compréhensible à mes yeux, le reste ne devrait pas pouvoir résister à une revue de code sérieuse.
(disclaimer : je programme professionnellement en C.)
l'innovation se trouve actuellement dans les extensions, je trouve, et elle, elle m'épate vraiment.