si la faille n'est pas exploitable, ce n'est plus un probleme de sécurité mais simplement un BUG.
Chez microsoft, on ne corrige pas les bugs a la volée cela n'est plus a démontrer.
Vu l'ampleur du probleme (zlib est utilisée de partout), il y a des TONNES de logiciels a corriger. Je trouve donc OPTIMAL de vérifier d'abord a quoi cela expose les clients avant de faire des release de patchs a gogo.
Si l'implementation de free() sur windows ne fait rien quand on l'appelle une seconde fois pour le meme segment de mémoire, il y a un bug dans l'algo de zlib qui n'est pas une faille, ni un probleme pour l'utilisateur (puisque ne crash pas le logiciel non plus). Si c'est le cas, je ne comprendrais pas que tout le monde fasse des release de patch pour un bug qui est pour le moins 'virtuel'.
Par contre il est vrai qu'un peu plus de certitude sur le diagnostique du cote windows ne ferai pas de mal.
[^] # Re: Verifions mieux BIS ;-)
Posté par PLuG . En réponse à la dépêche Le bug de Zlib touche aussi des produits Microsoft. Évalué à 10.
Chez microsoft, on ne corrige pas les bugs a la volée cela n'est plus a démontrer.
Vu l'ampleur du probleme (zlib est utilisée de partout), il y a des TONNES de logiciels a corriger. Je trouve donc OPTIMAL de vérifier d'abord a quoi cela expose les clients avant de faire des release de patchs a gogo.
Si l'implementation de free() sur windows ne fait rien quand on l'appelle une seconde fois pour le meme segment de mémoire, il y a un bug dans l'algo de zlib qui n'est pas une faille, ni un probleme pour l'utilisateur (puisque ne crash pas le logiciel non plus). Si c'est le cas, je ne comprendrais pas que tout le monde fasse des release de patch pour un bug qui est pour le moins 'virtuel'.
Par contre il est vrai qu'un peu plus de certitude sur le diagnostique du cote windows ne ferai pas de mal.