OpenSSL avait besoin d'entropie pour initialiser son générateur de nombres aléatoires. Il se basait évidemment sur des sources réputées sures (notamment /dev/random si disponible). La fonction qui ajoutait l'entropie avait besoin d'utiliser un buffer. Le raisonnement de l'auteur de l'époque c'était "Pourquoi s'embêter à le mettre à zéro avant de l'utiliser ?". Dans le pire des cas il est prédictible et ça ne change rien. Dans le meilleur des cas, ça rajoute encore un peu d'entropie à moindre coût (à coût négatif même puisque ça évite une opération).
Le souci de ce raisonnement c'est que le résultat faisait crier les analyseurs de code. Du coup, il y a eu tentative de correction, mais celle-ci a introduit un bug. La conséquence de celui-ci a fait que plus aucune source d'entropie n'était utilisée, sauf la toute première (le PID du process en cours, donc très peu d'entropie).
[^] # Re: Résumé
Posté par NicolasP . En réponse au lien 16 ans de CVE-2008-0166 (bug OpenSSL Debian) : casser DKIM et BIMI en 2024. Évalué à 3. Dernière modification le 14 mai 2024 à 21:08.
De mémoire c'était juste du bonus.
OpenSSL avait besoin d'entropie pour initialiser son générateur de nombres aléatoires. Il se basait évidemment sur des sources réputées sures (notamment /dev/random si disponible). La fonction qui ajoutait l'entropie avait besoin d'utiliser un buffer. Le raisonnement de l'auteur de l'époque c'était "Pourquoi s'embêter à le mettre à zéro avant de l'utiliser ?". Dans le pire des cas il est prédictible et ça ne change rien. Dans le meilleur des cas, ça rajoute encore un peu d'entropie à moindre coût (à coût négatif même puisque ça évite une opération).
Le souci de ce raisonnement c'est que le résultat faisait crier les analyseurs de code. Du coup, il y a eu tentative de correction, mais celle-ci a introduit un bug. La conséquence de celui-ci a fait que plus aucune source d'entropie n'était utilisée, sauf la toute première (le PID du process en cours, donc très peu d'entropie).