Là où ça passe mal pour la communauté postfix, c'est que l'entreprise SEC Consult qui a découvert la faille il y a 6 mois, en a d'abord uniquement évoqué les détails avec des acteurs privés (M$, Cisco, Google…) et des CERT, a obtenu un créneau de conf au CCC le 3 décembre pour finalement publier un papier d'analyse le 18 décembre décrivant comment exploiter la faille.
Sans jamais avoir averti la communauté postfix de l'existence de cette faille.
je trouve étonnant que les gros privilégiés en question (M$, Cisco, Google…) aient gardé le silence alors que ça se voyait bien que Postfix n'avait rien dit sur le sujet.
Je pense qu'il y a une boîte qui a réussi à se mettre à dos beaucoup d'utilisateurs et d'admin-sys.
"beaucoup" me parait assez optimiste. Le consensus semble être quand même qu'il faut pas gérer son mail (je pense que c'est une connerie, je le fait chez moi, mais bon, je parle pas de mon avis, mais de ce que je crois voir comme consensus, par exemple, les débats qu'on voit tout les mois sur /r/selfhosted, sur le forums des chatons, etc).
En plus, la faille est un peu naze, ça contourne le SPF, et c'est pas la fin du monde. Tu va peut être avoir un peu plus de spam, et/ou un peu plus de phising, c'est tout. Et même si le SPF aide pour lutter contre ça, c'est loin d'être ultime vu que dans une boite de taille conséquente, tu as toujours une tension entre "on contrôle d’où on en envoie" et "les équipes marketings/business passent leur temps à trouver des nouveaux outils par mail qu'on doit rajouter dans le SPF". Je regarde ce qu'on mets dans le SPF chez nous, il y a 84 ranges distincts.
De plus, la boite à l'origine de la faille explique sur sa page qu'ils ont d'abord contacté les services fautifs (microsoft, gmx, cisco), puis une autre liste avec d'autres fabricants (vendors en anglais).
Quand on lit tout, on comprends entre les lignes que le souci est que postfix/exim/etc n'y sont pas, et je pense que ce n'est pas forcément évident à voir. J'ajouterais que la doc de postfix sur comment soumettre un souci de sécu est inexistante, et celle d'exim est bien caché à 3 clics de la page du projet.
Donc c'est un peu rapide de trasher la boite alors que visiblement, le CERT a dit "faut aller la".
Vu que Postfix a une configuration pour bloquer ça maintenant, que le correctif long terme de Postfix est une option qui sera off par défaut, et que Cisco pense que ce n'est pas un souci (et que c'est le refus de Cisco qui a motivé la publication), peut être qu'il faut pas non plus trop se prendre la tête sur un truc qui ne va pas vraiment avoir des tas de conséquences et qui est un souci de communication sans fautif principal.
(sauf bien sur si le but est de vouloir faire du drama, mais ça se saurait si les réseaux sociaux étaient connu pour ça)
Postfix est libre mais le développement n'est pas aussi "ouvert" (pas de forge pour faire une poule requête ou de bugtracker public pour ouvrir un ticket) que d'autres projets si je me souviens bien.
Ça ne donne pas envie de contribuer 😢.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Quand on lit tout, on comprends entre les lignes que le souci est que postfix/exim/etc n'y sont pas, et je pense que ce n'est pas forcément évident à voir.
Il y a aussi le fait que la faille a été rendue publique quelques jours avant noël, gâchant hrobablement un peu les vacances des mainteneurs de postfix qui ont dû passer du temps à sortir une version corrective à cette période. La raison semble être que l'entreprise pourra ainssi présenter ses travaux lors du CCC cette semaine.
Ce n'est peut-être pas intentionnel, mais c'est une chose à laquelle ils auraient pu penser (du même niveau que "on ne met pas en prod un vendredi")
Posté par Misc (site web personnel) .
Évalué à 5.
Dernière modification le 28 décembre 2023 à 11:27.
L'entreprise dit justement qu'ils ont publiés en décembre avant noël parce que sinon, c'était rendu publique pendant les vacances, ce qui est pire. Le 18 décembre, ça laisse une semaine, c'est pas non plus le jour de noël. Si on regarde la timeline de postfix, le correctif est dispo le lendemain, et sans doute validé assez vite.
Ce n'est peut-être pas intentionnel, mais c'est une chose à laquelle ils auraient pu penser (du même niveau que "on ne met pas en prod un vendredi")
Moi je mets en prod le vendredi, donc bon, je suis pas convaincu.
On arrête pas de dire qu'il y a pas de garantie avec le logiciel libre (j'invite pas, c'est dans la GPL), donc je trouve contre productif et mal placé de prétendre le contraire. Une bonne part de la communauté râle quand quelqu'un envoie un mail pour demander "c'est quoi le delai pour log4j" à un projet libre, etc, mais en même temps, c'est aussi parce qu'on (la communauté) a tendance à agir comme si on était responsable. Il faut pas s'étonner ensuite qu'on oublie la différence.
Comme l'a dit mon ancien chef, si tout marche sans souci, on oublie que tu existes et pourquoi tu es la. Exemple: openssl et heartbleed, exemple 2: log4j, etc.
Compte tenu des échanges, il y a maintenant de quoi faire un journal.
C'est dans ma todo-liste de 2024+ mais si quelqu'un se sent pousser des ailes pour le faire, n'hésitez-pas.
Merci
Bonnes fêtes!
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
# En gros
Posté par GG (site web personnel) . Évalué à 10. Dernière modification le 25 décembre 2023 à 17:21.
Je copie colle des bouts de trucs en guise de citations :
je trouve étonnant que les gros privilégiés en question (M$, Cisco, Google…) aient gardé le silence alors que ça se voyait bien que Postfix n'avait rien dit sur le sujet.
Je pense qu'il y a une boîte qui a réussi à se mettre à dos beaucoup d'utilisateurs et d'admin-sys.
Oui, faudrait un journal…
(et corriger la faute dans le titre, s'il vous plait) (en sois, c'est pas grave, n'est ce pas?)
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: En gros
Posté par Misc (site web personnel) . Évalué à 10.
"beaucoup" me parait assez optimiste. Le consensus semble être quand même qu'il faut pas gérer son mail (je pense que c'est une connerie, je le fait chez moi, mais bon, je parle pas de mon avis, mais de ce que je crois voir comme consensus, par exemple, les débats qu'on voit tout les mois sur /r/selfhosted, sur le forums des chatons, etc).
En plus, la faille est un peu naze, ça contourne le SPF, et c'est pas la fin du monde. Tu va peut être avoir un peu plus de spam, et/ou un peu plus de phising, c'est tout. Et même si le SPF aide pour lutter contre ça, c'est loin d'être ultime vu que dans une boite de taille conséquente, tu as toujours une tension entre "on contrôle d’où on en envoie" et "les équipes marketings/business passent leur temps à trouver des nouveaux outils par mail qu'on doit rajouter dans le SPF". Je regarde ce qu'on mets dans le SPF chez nous, il y a 84 ranges distincts.
De plus, la boite à l'origine de la faille explique sur sa page qu'ils ont d'abord contacté les services fautifs (microsoft, gmx, cisco), puis une autre liste avec d'autres fabricants (vendors en anglais).
https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
Quand on lit tout, on comprends entre les lignes que le souci est que postfix/exim/etc n'y sont pas, et je pense que ce n'est pas forcément évident à voir. J'ajouterais que la doc de postfix sur comment soumettre un souci de sécu est inexistante, et celle d'exim est bien caché à 3 clics de la page du projet.
Donc c'est un peu rapide de trasher la boite alors que visiblement, le CERT a dit "faut aller la".
Vu que Postfix a une configuration pour bloquer ça maintenant, que le correctif long terme de Postfix est une option qui sera off par défaut, et que Cisco pense que ce n'est pas un souci (et que c'est le refus de Cisco qui a motivé la publication), peut être qu'il faut pas non plus trop se prendre la tête sur un truc qui ne va pas vraiment avoir des tas de conséquences et qui est un souci de communication sans fautif principal.
(sauf bien sur si le but est de vouloir faire du drama, mais ça se saurait si les réseaux sociaux étaient connu pour ça)
[^] # Re: En gros
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Postfix est libre mais le développement n'est pas aussi "ouvert" (pas de forge pour faire une poule requête ou de bugtracker public pour ouvrir un ticket) que d'autres projets si je me souviens bien.
Ça ne donne pas envie de contribuer 😢.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: En gros
Posté par orfenor . Évalué à 2.
si si
https://github.com/wietse-postfix/postfix-dukhovni
Faut prendre le temps de parcourir la liste de discussion des développeurs, camarade!
[^] # Re: En gros
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
Il y a aussi le fait que la faille a été rendue publique quelques jours avant noël, gâchant hrobablement un peu les vacances des mainteneurs de postfix qui ont dû passer du temps à sortir une version corrective à cette période. La raison semble être que l'entreprise pourra ainssi présenter ses travaux lors du CCC cette semaine.
Ce n'est peut-être pas intentionnel, mais c'est une chose à laquelle ils auraient pu penser (du même niveau que "on ne met pas en prod un vendredi")
[^] # Re: En gros
Posté par Misc (site web personnel) . Évalué à 5. Dernière modification le 28 décembre 2023 à 11:27.
L'entreprise dit justement qu'ils ont publiés en décembre avant noël parce que sinon, c'était rendu publique pendant les vacances, ce qui est pire. Le 18 décembre, ça laisse une semaine, c'est pas non plus le jour de noël. Si on regarde la timeline de postfix, le correctif est dispo le lendemain, et sans doute validé assez vite.
Moi je mets en prod le vendredi, donc bon, je suis pas convaincu.
On arrête pas de dire qu'il y a pas de garantie avec le logiciel libre (j'invite pas, c'est dans la GPL), donc je trouve contre productif et mal placé de prétendre le contraire. Une bonne part de la communauté râle quand quelqu'un envoie un mail pour demander "c'est quoi le delai pour log4j" à un projet libre, etc, mais en même temps, c'est aussi parce qu'on (la communauté) a tendance à agir comme si on était responsable. Il faut pas s'étonner ensuite qu'on oublie la différence.
Comme l'a dit mon ancien chef, si tout marche sans souci, on oublie que tu existes et pourquoi tu es la. Exemple: openssl et heartbleed, exemple 2: log4j, etc.
# liens
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Historique https://social.wildeboer.net/@jwildeboer/111635854222526516
Pas que Postfix
Suivi pour Postfix chez Debian https://security-tracker.debian.org/tracker/CVE-2023-51764
[^] # Re: liens
Posté par GG (site web personnel) . Évalué à 3. Dernière modification le 25 décembre 2023 à 17:24.
Ah oui, je dois vérifier que Sendmail est protégé, sur mes serveurs… en effet. c'est listé.
Merci
Peut être ajouter sendmail et exim après le mot faille, dans le titre?
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
# Super!
Posté par GG (site web personnel) . Évalué à 3.
Compte tenu des échanges, il y a maintenant de quoi faire un journal.
C'est dans ma todo-liste de 2024+ mais si quelqu'un se sent pousser des ailes pour le faire, n'hésitez-pas.
Merci
Bonnes fêtes!
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Super!
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.