Comment, 16 ans après, et par un hasard de l'histoire, un nombre surprenant de serveurs e-mails utilisent des clefs faibles générées sous Debian à la grande époque où Debian avait cassé le générateur de nombres aléatoires d'OpenSSL en pensant bien faire.
Et évidemment, avant que quelqu'un d'autre ne le fasse, le XKCD qui va avec:
Posté par Yth (Mastodon) .
Évalué à 10 (+8/-0).
Dernière modification le 14 mai 2024 à 11:13.
Pour résumer sans XKCD:
- en 2008 Debian a patché OpenSSL, provoquant un gros problème où les clés générées étaient très restreinte à genre quelques milliers possibles ;
- ils ont corrigés depuis longtemps quand même hein ;
- durant la période d'activité du bug, des gens, dont une boîte en particulier (mais j'ai pas regardé qui), a généré plein de clés DKIM ;
- le DKIM est un système automagique et transparent pour le final-user de signature des emails pour valider qu'il a bien été envoyé par le serveur duquel il prétend venir, ça permet de réduire le SPAM ;
- DKIM en tant que tel n'a pas de problème de sécurité lié à ce bug, en tout cas si vous avez un serveur DKIM, a priori tout va bien, sauf si bien sûr vous avez générés vos clés lors du bug Debian.
Bref, sur un million de clés DKIM très utilisées sur le grand interweb, environ un tiers ont été générées avec ce bug, c'est salement plein quand même, faut être honnête.
Le résultat c'est qu'il est plutôt facile (probablement) de casser la signature DKIM de ces serveurs là, et donc de faire glisser du SPAM comme un email chez Gmail.
J'ai lu très en diagonale, donc j'ai pu commettre des erreurs, mais disons qu'a priori mon propre serveur DKIM datant de pas-2008, et sous pas-Debian, n'a aucune raison d'être problématique.
À noter que ça n'empêche pas ledit Google d'envoyer paître silencieusement mes emails vers chez lui, ce qui m'arrange : j'ai ainsi une forme d'immunité contre l'extra-territorialité des lois Ricaines.
Et pour ceux qui veulent tout savoir le patch de Debian corrigeait des accès à de la mémoire non initialisée dont le contenu (réputé aléatoire) était lu (ce qui causait un warning à la compilation) et utilisé comme source pour le RNG. Evidemment, une fois que c'était initialisé à 0 c'était beaucoup moins aléatoire.
Posté par NicolasP .
Évalué à 3 (+3/-1).
Dernière modification le 14 mai 2024 à 21:08.
contenu (réputé aléatoire)
C'est pas très fragile comme hypothèse ça ?
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).
Vu la conséquence j'aurais du mal à dire que c'est du bonus.
Dans le pire des cas il est prédictible et ça ne change rien.
L'histoire lui a donné tord. Surtout qu'il me semble qu'il existait à minima des patch pour qu'une page donnée par l'OS soit mise à 0.
Le souci de ce raisonnement c'est que le résultat faisait crier les analyseurs de code.
Quand on fait quelque chose de bizarre et qui se veut intelligent, ça vaut le coût de mettre un commentaire (après peut être que le développeur Debian l'a ignoré).
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).
La chaine me paraît vraiment bizarre. On initialise avec un fort avant d'utiliser un (cs)prng. Démarrer avec une source faible voir inexistante (en fait sur la quelle il n'y a aucune raison d’émettre une hypothèse sur son contenu) me parait bizarre.
Posté par NicolasP .
Évalué à 3 (+2/-0).
Dernière modification le 14 mai 2024 à 21:49.
De mémoire c'était juste du bonus.
Vu la conséquence j'aurais du mal à dire que c'est du bonus.
Dans le pire des cas il est prédictible et ça ne change rien.
L'histoire lui a donné tord. Surtout qu'il me semble qu'il existait à minima des patch pour qu'une page donnée par l'OS soit mise à 0.
Attention, le bug n'a pas été causé par ce bonus. Si l'OS ou n'importe quoi d'autre avait juste mis le contenu de ce buffer à 0, ça n'aurait eu aucune conséquence notable dans la plupart des situations, juste le bonus aurait disparu.
Le bug a été causé par quelqu'un qui a voulu corriger le code en se disant que l'intérêt du bonus est faible par rapport au fait que ça lève des warnings. Et il y a eu une erreur dans la correction. Je ne me souviens plus des détails mais je crois qu'au lieu de mettre le buffer à 0 avant sa première utilisation, il a été mis à 0 après qu'il ait été rempli avec la vraie source d'entropie. Ce qui a rendu facilement prédictible tous les nombres aléatoires générés.
En fait il y avait un usage très problématique pour utiliser valgrind, mais le DD l'a aussi appliqué sur des endroits légitimes qui étaient correctement initialisés par une source d'entropy
Il a posé la question sur openssl-dev, mais la liste de diffusion openssl-dev n'était plus utilisées pour parler du développement d'openssl et la liste de diffusion où il aurait pu avoir des retours n'était en pratique pas publique
C'est marrant on peut tomber sur cette discussion où ça a était choisi et ou on voit les certaines réactions 2 ans après et où il y a la même discussion qu'ici sur l'utilisation de données non initialisés comme source d'entropie.
# Résumé
Posté par nud . Évalué à 9 (+7/-0).
Comment, 16 ans après, et par un hasard de l'histoire, un nombre surprenant de serveurs e-mails utilisent des clefs faibles générées sous Debian à la grande époque où Debian avait cassé le générateur de nombres aléatoires d'OpenSSL en pensant bien faire.
Et évidemment, avant que quelqu'un d'autre ne le fasse, le XKCD qui va avec:
[^] # Re: Résumé
Posté par Yth (Mastodon) . Évalué à 10 (+8/-0). Dernière modification le 14 mai 2024 à 11:13.
Pour résumer sans XKCD:
- en 2008 Debian a patché OpenSSL, provoquant un gros problème où les clés générées étaient très restreinte à genre quelques milliers possibles ;
- ils ont corrigés depuis longtemps quand même hein ;
- durant la période d'activité du bug, des gens, dont une boîte en particulier (mais j'ai pas regardé qui), a généré plein de clés DKIM ;
- le DKIM est un système automagique et transparent pour le final-user de signature des emails pour valider qu'il a bien été envoyé par le serveur duquel il prétend venir, ça permet de réduire le SPAM ;
- DKIM en tant que tel n'a pas de problème de sécurité lié à ce bug, en tout cas si vous avez un serveur DKIM, a priori tout va bien, sauf si bien sûr vous avez générés vos clés lors du bug Debian.
Bref, sur un million de clés DKIM très utilisées sur le grand interweb, environ un tiers ont été générées avec ce bug, c'est salement plein quand même, faut être honnête.
Le résultat c'est qu'il est plutôt facile (probablement) de casser la signature DKIM de ces serveurs là, et donc de faire glisser du SPAM comme un email chez Gmail.
J'ai lu très en diagonale, donc j'ai pu commettre des erreurs, mais disons qu'a priori mon propre serveur DKIM datant de pas-2008, et sous pas-Debian, n'a aucune raison d'être problématique.
À noter que ça n'empêche pas ledit Google d'envoyer paître silencieusement mes emails vers chez lui, ce qui m'arrange : j'ai ainsi une forme d'immunité contre l'extra-territorialité des lois Ricaines.
[^] # Re: Résumé
Posté par nud . Évalué à 4 (+2/-0).
Et pour ceux qui veulent tout savoir le patch de Debian corrigeait des accès à de la mémoire non initialisée dont le contenu (réputé aléatoire) était lu (ce qui causait un warning à la compilation) et utilisé comme source pour le RNG. Evidemment, une fois que c'était initialisé à 0 c'était beaucoup moins aléatoire.
[^] # Re: Résumé
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
C'est pas très fragile comme hypothèse ça ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Résumé
Posté par NicolasP . Évalué à 3 (+3/-1). 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).
[^] # Re: Résumé
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Vu la conséquence j'aurais du mal à dire que c'est du bonus.
L'histoire lui a donné tord. Surtout qu'il me semble qu'il existait à minima des patch pour qu'une page donnée par l'OS soit mise à 0.
Quand on fait quelque chose de bizarre et qui se veut intelligent, ça vaut le coût de mettre un commentaire (après peut être que le développeur Debian l'a ignoré).
La chaine me paraît vraiment bizarre. On initialise avec un fort avant d'utiliser un (cs)prng. Démarrer avec une source faible voir inexistante (en fait sur la quelle il n'y a aucune raison d’émettre une hypothèse sur son contenu) me parait bizarre.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Résumé
Posté par NicolasP . Évalué à 3 (+2/-0). Dernière modification le 14 mai 2024 à 21:49.
Attention, le bug n'a pas été causé par ce bonus. Si l'OS ou n'importe quoi d'autre avait juste mis le contenu de ce buffer à 0, ça n'aurait eu aucune conséquence notable dans la plupart des situations, juste le bonus aurait disparu.
Le bug a été causé par quelqu'un qui a voulu corriger le code en se disant que l'intérêt du bonus est faible par rapport au fait que ça lève des warnings. Et il y a eu une erreur dans la correction. Je ne me souviens plus des détails mais je crois qu'au lieu de mettre le buffer à 0 avant sa première utilisation, il a été mis à 0 après qu'il ait été rempli avec la vraie source d'entropie. Ce qui a rendu facilement prédictible tous les nombres aléatoires générés.
[^] # Re: Résumé
Posté par barmic 🦦 . Évalué à 4 (+2/-0). Dernière modification le 14 mai 2024 à 22:15.
Je suis tombé là dessus. C'est intéressant :
C'est marrant on peut tomber sur cette discussion où ça a était choisi et ou on voit les certaines réactions 2 ans après et où il y a la même discussion qu'ici sur l'utilisation de données non initialisés comme source d'entropie.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Résumé
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
S'ils n'utilisaient que DKIM pour bloquer le spam
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.