Faille de sécurité importante dans Sendmail

Posté par  . Modéré par Amaury.
Étiquettes :
0
3
mar.
2003
Sécurité
Un faille de sécurité vient d'être découverte dans Sendmail. Celle-ci peut donner un accès root à une personne non autorisée. Il n'y a pas d'exploit connu à l'heure actuelle, mais chacun est très fortement encouragé à patcher son système ou à passer à la dernière version, dans les plus brefs délais.

NdM: Encore un buffer overflow dans Sendmail. La protection contre l'exécution de la pile semble être inefficace ici. Pas encore d'infos sur l'efficacité de StackGuard/ProPolice vis à vis de cette faille (en fait, il n'y a pas encore d'exploit pour tester si ProPolice fonctionne ou pas dans ce cas). RedHat et OpenBSD semblent être les premiers à avoir livré des patchs pour leurs systèmes respectifs.

N'hésitez pas à poster en commentaire les URIs vers les patchs de votre système/distribution favorite !

Aller plus loin

  • # Ooops

    Posté par  . Évalué à 10.

    J'ai fait un up2date, comme d'hab (suis sous redhat) :

    Error Message:
    Demo service for serveur 1002052815 limited due to high load
    Error Class Code: 51
    Error Class Info:
    Demo service currently disabled due to high load. If you would like
    to see Red Hat's policies on Demo service, or find out how you can
    purchase a subscription service and receive priority download access,
    please go to http://rhn.redhat.com/preview/index.pxt(...)

    Retour sur la methode manuelle qui marche.
    • [^] # Re: Ooops

      Posté par  . Évalué à 10.

      Normal comme a chaque fois qu'une faillie sur un service majeur est patché (ssh, apache...), les serveurs de redhat pour evité d'étre surchargé coupe ce service gracieux aux utilisateurs des versions gratuites.

      Pour rappel RedHat vend avent tout des services basés sur ses distribes, cette methode ne me chock pas, de plus tout le monde le fait.
  • # Re: Faille de sécurité importante dans Sendmail

    Posté par  . Évalué à 10.

    C'est peut-être l'ocasion de passer a Postfix.
    En plus la doc est diponible en français:
    http://linuxfr.org/2002/12/18/10717.html(...)
    Bon, c'est pas bien de profiter des malheurs des autres. Puis la fuite en avant n'est pas une solution.
    Au fait y'a quoi comme server de mail autre que Sendmail et Postfix?
    • [^] # Re: Faille de sécurité importante dans Sendmail

      Posté par  . Évalué à 5.

      il y a qmail : http://qmail.free.fr/(...) qui a l'air assez sympa
      • [^] # Re: Faille de sécurité importante dans Sendmail

        Posté par  (site web personnel) . Évalué à 2.

        Il l'est
        Il a été concu dès le départ par Berstein comme un logiciel sécurisé à l'inverse de Sendmail
      • [^] # Re: Faille de sécurité importante dans Sendmail

        Posté par  . Évalué à 4.

        sauf que qmail c est pas libre
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  (site web personnel) . Évalué à 3.

          Pas libre au sens de l'osi ou gnu
          mais il offre tout de même de sacrés libertés

          Et puis, j'en ai marre de la mentalité qui fait que les gens critiquent les choix des auteurs.
          Si il veut placer une license plus restrictive, c'est son problème, pas le notre.
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  . Évalué à 10.

            oui tout a fait c est son probleme , pareil pour exchange qui n est pas libre non plus , heureusement postfix et exims sont libres eux .
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  . Évalué à 9.

            "J'en ai marre de la mentalité qui fait que les gens critiquent les choix des auteurs"
            C'est vrai quoi, merde ! Free Software, BSD, MIT, X11, Artistic, proprio, les licences on s'en fout, hein, tant que ça marche ! Même le CLUF Microsoft, il est pas si mal que ça finalement, hein ? C'est suffisant, on peut déjà utiliser le soft, on va quand même pas critiquer les auteurs de chez Microsoft, il nous permettent d'accéder à leur soft, c'est déjà bien gentil.

            Sans rire, où as-tu vu une critique de l'auteur (DJ Bernstein en l'occurence) dans les posts précédents ? On se contentait de dire que ce n'était ni libre ou sens de la FSF, ni libre au sens de l'OSI, c'est tout. C'est devenu une critique d'exprimer un simple fait maintenant ?
            • [^] # Et Vlan !

              Posté par  . Évalué à -2.

              Salut Djrom,

              C'est vrai quoi, merde ! Free Software, BSD, MIT, X11, Artistic, proprio, les licences on s'en fout, hein, tant que ça marche ! Même le CLUF Microsoft, il est pas si mal que ça finalement, hein ? C'est suffisant, on peut déjà utiliser le soft, on va quand même pas critiquer les auteurs de chez Microsoft, il nous permettent d'accéder à leur soft, c'est déjà bien gentil.

              Ben oui, quoi on se demande ce que nous faisons tous ici. Après tout nous sommes des gens civilisés non, pourquoi linufr n'ouvre t-il pas ses colonnes à la promotions des softs non libre ?

              "Microsoft Power !" Heu... là je crois que la dose de poil de Gnou était un peu chargée là (excusez moi d'avoir penser tout haut :))
              • [^] # Au nom de tous mes [-],

                Posté par  . Évalué à 3.

                Houlà, y a des gens qui font une telle fixation sur "Microsoft" que :

                pseudo_cote = -1 /*d'office! faut bien initialiser une variable, non ?/
                debut (lecture)
                si (nb (mot_interdit == "microsoft") >= 1) alors
                pseudo_cote = pseudo_cote -1
                finsi
                tantque ((doigt != fatigué) || (souris != cramé))
                retour debut
                fin tantque
                fin (lecture)
                pseudo_cote = pseudo_cote -1 /* juste pour le plaisir */

                Faut pas uniquement s'en tenir à une première lecture, et rager sur ma dernière phrase, mais juger l'ensemble de mon post. La phrase finale est "ironique" (Mieux vaut preciser, certains ne comprennent pas enocre que l'on puisse faire de l'humour avec "Microsoft").

                Là, je vais recolter au minimum 3*[-] pour sur . Le reste... depend du doigt ou de l solidité de la souris ;)
            • [^] # Re: Faille de sécurité importante dans Sendmail

              Posté par  (site web personnel) . Évalué à 6.

              Oups je viens de me relire, j'étais un peu violent

              Pour remettre les choses dans leur contexte, le problème que j'ai rencontré (par sur ce post mais autre part, de plus c'est moi qui aie parlé de l'osi et de la fsf), c'est que j'ai remarqué que les gens parlent de qmail sans savoir la license précisement.

              Certes qmail n'est pas libre au sens osi ou gnu, mais il apporte tout de même certaines libertés de bases (les restrictions étant au niveau des sources pour ceux qui ne le savent pas)
              Bref séparer les logiciels, en deux catégories : les libres (sendmail, exim, postfix) dc les bons, et les nons libres (qmail, exchange) me parait tout à fait farfelu.

              De plus, je voudrais ajouter que les utilisateurs ont des droits sur un logiciel dans le cadre de la license. Il est donc libre de l'accepter ou de la refuser si elle ne lui plait pas
              Ainsi si je pense que la GNU GPL interfère avec mon droit au niveau des licenses (ce qui est vrai), je n'ai qu'à ne pas utiliser le logiciel.

              Et encore désolé pour ce début de troll
              • [^] # Re: Faille de sécurité importante dans Sendmail

                Posté par  (site web personnel) . Évalué à 2.

                (les restrictions étant au niveau des sources pour ceux qui ne le savent pas)
                les restrictions étant au niveau de la redistribution pour ceux qui ne le savent pas)
              • [^] # Re: Faille de sécurité importante dans Sendmail

                Posté par  (site web personnel) . Évalué à 10.

                Un troll ? Je plonge !



                En fait si, on le sait, mais ce qui m'embête chez Bernstein c'est la justification de ses licences. On a l'impression qu'il est persuadé d'avoir les meilleures solutions, et voudrait donc que tout le monde fasse comme lui. Or, c'est aller un peu vite en besogne. Les problèmes qu'il cite à [http://cr.yp.to/compatibility.html(...)] sont certes vrais, mais il est (AMHA) présomptueux d'imposer ses choix aux autres : ceux-ci ont parfois de bonnes raisons (au moins aussi bonnes que les siennes, du moins) de procéder autrement (genre, on a fait toute une distrib' avec une certaine architecture, on va éviter de tout chambouler pour M. DJB). C'est pourquoi Debian fournit, ce me semble, des paquets qui téléchargent et installent les softs DJB à la manière Debian, histoire de feinter la licence. Je trouve que c'est triste d'en arriver là, travailler avec des initiatives comme la LSB serait sans doute plus productif, même si (encore une fois) je suis d'accord avec le fait que les problèmes qu'il décrit sont gênants et devront être traités à plus ou moins long terme. C'est juste que je préférerais que ça se fasse par consensus plutôt que par licences interposées...

                Envoyé depuis mon PDP 11/70

              • [^] # Re: Faille de sécurité importante dans Sendmail

                Posté par  (site web personnel) . Évalué à 2.

                De plus, je voudrais ajouter que les utilisateurs ont des droits sur un logiciel dans le cadre de la license. Il est donc libre de l'accepter ou de la refuser si elle ne lui plait pas

                Justement, il n'y a pas de license avec qmail, il diffuse les sources et c'est soumis simplement à la propriété intellectuelle. On peut diffuser des patchs pour les sources parce que c'est vu comme des annotations. Le truc, c'est que DJB dévoile au fur et à mesure sa version de la propriété intellectuelle. QMail a été viré d'OpenBSD parce qu'il était en fait interdit de modifier la hiérarchie des fichiers utilisée.
                • [^] # Re: Faille de sécurité importante dans Sendmail

                  Posté par  (site web personnel) . Évalué à 3.

                  QMail a été viré d'OpenBSD parce qu'il était en fait interdit de modifier la hiérarchie des fichiers utilisée.

                  C'est plus compliqué que ça. En gros, il y avait dans OpenBSD du patch au vol qui modifiait le comportement de qmail, ce qui est parfaitement permis. Mais par contre, pour diffuser un binaire il faut qu'il s'agisse de qmail version "pure". Un jour, les gens d'OpenBSD se sont bien pris la tête avec Bernstein à ce sujet et ils ont donc arrêté la diffusion, même avec le patch automatique. Enfin, c'est ce que j'ai compris.
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  (site web personnel) . Évalué à 8.

          Si pour toi, pas libre signifie qu'il n'a pas une license GPL, et bien saches que Postfix non plus ne l'est pas: il est sous licence publique IBM. Exim est par contre sous licence GPL, mais c'est pas pour ça qu'il est mieux que Postfix ou qmail... au contraire.
          Il faut arrêter de faire l'amalgame, la GPL n'est pas la seule licence permettant l'open Source et le libre.
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  (site web personnel) . Évalué à 0.

            Je n'ai jamais dit qu'il fallait être en GPL pour être libre ... vu que je parle de l'osi ou de gnu (fsf)

            Par contre, j'ai au regret de te dire que selon la fsf - http://www.gnu.org/philosophy/license-list.fr.html(...) - qui est tout de même une référence en ce domaine. Postfix est libre mais non compatible GPL ce qui est deux notions différentes.
            • [^] # Re: Faille de sécurité importante dans Sendmail

              Posté par  (site web personnel) . Évalué à 1.

              Je répondais à Houplaboom qui pretextait que qmail n'était pas libre. Et je suis tout à fait d'accord avec toi pour dire que libre et GPL sont 2 notions différentes, et j'ai posté uniquement dans ce but: Il ne faut pas décrédibiliser un soft parce qu'il n'est pas GPL.
              Ensuite, c'est vrai que j'ai eu le troll facile à propose d'exim mais cela n'engage que moi. D'ailleurs je n'ai pas dit qu'Exim était nul comparé à Postfix ou qmail comme le dit B. Massot, j'ai juste laisse sous entendre qu'il était moins bien. Je n'argumenterai pas sur ce point, c'est totalement subjectif genre "c moi qui ait la plus grosse".
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  . Évalué à 1.

            Si pour toi, pas libre signifie qu'il n'a pas une license GPL
            Il n'a JAMAIS dit ça.

            Exim [...] mais c'est pas pour ça qu'il est mieux que Postfix ou qmail... au contraire.
            T'as quoi comme arguments concrets pour dire qu'Exim est nul comparé à Postfix et qmail ?
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  (site web personnel) . Évalué à 9.

          Je reconnaît la un argument ultra puissant. Ca serait sympa de ne pas recommencer le troll de 25 km de long sur la licence de dnsdjb en faisant simplement s/dnsdjb/qmail/g. Parce que franchement, les arguments ne volaient pas haut.

          Il y a de nombreuses raisons de préférer les logiciels libres aux logiciels propriétaires. La plupart de ces raisons ne s'appliquent pas à qmail, c'est pourquoi, même s'il n'est pas libre, la comparaison avec un logiciel propriétaire comme exchange est totalement débile. Le seul véritable argument qui tiennent la route concernant qmail est le fait qu'on ne peut pas partager autour de ce logiciel : on ne peut pas redistribuer de version patchée, on ne peut pas piquer un bout de code, etc. Tous les autres avantages du logiciel libre s'appliquent, comme par exemple l'accès aux sources, le fait qu'on puisse faire ce qu'on veut du programme en interne (en particulier le patcher), le fait qu'on puisse redistribuer les patchs, etc. Bref, en gros aucun rapport avec le CLUF classique.
    • [^] # Re: Faille de sécurité importante dans Sendmail

      Posté par  (site web personnel) . Évalué à 3.

      exim
      qmail
    • [^] # Re: Faille de sécurité importante dans Sendmail

      Posté par  . Évalué à 4.

      C'est toujours pareil...
      Quand il y a un trou de sécurité dans un produit très utilisé, y en toujours pour vendre le concurrent (voir l'épisode bind).

      Ceci dit, j'y connais pratiquement rien en serveur mail et postfix est peut-être super morter. Mais il faudrait argumenter que de sauter sur un trou de sécurité qui peut arriver à tous les projets.

      > Au fait y'a quoi comme server de mail autre que Sendmail et Postfix?
      exim : http://www.exim.org/(...)
      Je crois qu'il est installé par défaut sur Debian. Donc déjà assez utilisé, débuggué.
      • [^] # Re: Faille de sécurité importante dans Sendmail

        Posté par  . Évalué à 10.

        Déjà, il suffit de comparer les fichiers de config de Postfix et Sendmail pour ce rendre compte qu'a priori Postfix est mieux...
      • [^] # Re: Faille de sécurité importante dans Sendmail

        Posté par  . Évalué à 10.

        Oui c'est vrai mais postfix a été conçu dès le départ sécurisé.
        Il n'y a pas de logiciel miracle mais on ne peut pas faire pire que sendmail, ça c'est sûr. Sur ce coup je ne dirais pas que postfix est le meilleur mais que sendmail est le moins bon.
        Postfix a mis du temps avant d'arriver à point mais le résultat me semble positif.
        Ce n'est pas seulement le logiciel qui fait sa sécurité mais aussi sa facilité de configuration. ça sert à rien d'avoir un monstre qu'on met des heures à configurer si au final on n'est pas sûr de sa config. Postfix est simple à configurer donc on maîtrise facilement une bonne configuration et donc une meilleure sécurité quelque part, non ?
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  . Évalué à 7.

          Heuuuu, je ne suis pas sûr (mais j'aime bien parler de ce que je ne connais pas alors...) mais je crois que sendmail est un des premiers serveurs de mail "modernes" qui a tourné sous Unix. Alors au fure et à mesure du temps il a "évolué" pour être une grosse usine à gaz qui intrinsèquement, est insécurisée. (La doc papier pèse quelques Kg).

          Maintenant parler du meilleur ou du moins bon ... je pense que le meilleur outil reste celui qu'on sait utiliser et qui répond aux besoins postfix et exim marchent très biens, qmail est célèbre aussi (quoique non libre) car le développement s'est arrété il y'a quelques années : motif "rien à changer".

          Voila voila ...

          Le Père Fourras.

          PS : et alors, Roff est plus vieux que TeX ?
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  . Évalué à 2.

          Pire que Sendmail ... hum ... INN et wmc² :)
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  . Évalué à -1.

          >ça sert à rien d'avoir un monstre qu'on met des heures à configurer

          Ouais, bon, faut pas exagérer non plus avec linuxconf, ton sendmail est proprement configuré en moins de 5 mn.

          Et en terme de fonctionnalités, Postfix vaut sendmail ?
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  (site web personnel) . Évalué à 10.



            Oui, mais est-ce que tu *comprends* la config' que Linuxconf a générée ? Est-ce que, lorsqu'un problème va se faire jour, tu vas pouvoir ouvrir ton sendmail.cf, lire les logs et te dire « ah mais c'est bien sûr, c'est le ruleset 92 qui met le souk » ? Si oui, eh bien je te tire mon chapeau[*], moi je suis tellement terrorisé que je ne m'aventure pas à déboguer le sendmail.cf au-delà de la partie lisible (les options 'O Foobar=truc') et je laisse le sendmail.mc me générer la purée (malgré la présence du gros bouquin O'Reilly qui va bien sur mon bureau). En bref, il vaut mieux que rien de véritablement bizarre ne se passe...

            Par contraste, avec une trentaine de lignes, ton Postfix il est configuré, et il marche bien. Et tu comprends ce que tu fais, ce qui est un avantage indéniable (j'aime aussi l'option soft_bounce qui est un must pour les tests périlleux. Mais c'est hors-sujet). En bref, avec Sendmail, tu as un programme qui marche sans que tu saches pourquoi. C'est hyper dangereux, AMHA.



            Franchement, pour l'instant je n'ai rien vu manquer à l'appel dans Postfix. Il a même des trucs que Sendmail n'a pas, comme des vrais domaines virtuels, la possibilité d'avoir un backend SQL, des tables de gestion d'accès plus fines et avec support des regex, etc. (prière de me corriger si je me goure et que Sendmail a en fait ces fonctions !). Bref, je pense que Postfix (ou Exim, qui est pas mal non plus) valent largement Sendmail. Mais c'est juste mon expérience perso, après il y a peut-être des domaines où ils pêchent, à toi de voir en fonction de tes besoins (comme toujours, d'ailleurs)...

            [*] si, si, vraiment. Ce n'est pas un sarcasme !

            Envoyé depuis mon PDP 11/70

      • [^] # Re: Faille de sécurité importante dans Sendmail

        Posté par  (site web personnel) . Évalué à 3.

        Sendmail est une merde. Qu'est-ce que tu veux qu'on y fasse ? Il y a eu des dizaines de bug de sécurité dans sendmail, dont certains extrêmement grave. Au contraire, il n'y a jamais eu de bug de sécurité dans qmail. Pour postfix, il y a eu un bug pas très clair, mais rien de grave. qmail et postfix ont été conçu dès le départ pour être efficaces et sûrs, ils n'ont pas été patchés dans tous les sens pour corriger une conception défaillante (car antédiluvienne) doublée d'un système de configuration indigeant.

        Bref, il n'y aucune raison objective pour garder sendmail. D'ailleurs je salue les distributions qui ne l'installent pas par défaut, comme debian ou mandrake (et sûrement d'autres).
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  . Évalué à -2.

          > Sendmail est une merde.

          C'est évident. C'est même pour ça qu'il est le plus utilisé par les gros sites. C'est pour justifier les salaires des admins. C'est aussi pour ça qu'il est utilisé par tous les Unix commerciaux. C'est pour bien montrer que le free software c'est de la merde.

          > Il y a eu des dizaines de bug de sécurité dans sendmail

          Sendmail est une honte. D'ailleur le trou de sécurité précédent date d'octobre 2001. Plus d'un trou de sécurité tout les deux ans. Scandaleux. Y a que le noyau Linux, php, apache, ssh, etc... pour faire pire.
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  . Évalué à 3.

            bon ecoute c est par parce que redhat ( et ca doit etre la seule ) met sendmail par default que c est bien , faut se faire une raison sendmail est une merde bien bloat et pas secure. REdhat fais une tres grosse erreur de le mettre par default , les admins qui gardent sendmail sont simplement des dynos qui veulent justifier leur salaire parce que y a qu eux qui savent configurer cette daube .
            • [^] # Re: Faille de sécurité importante dans Sendmail

              Posté par  . Évalué à 3.

              > bon ecoute c est par parce que redhat ( et ca doit etre la seule )
              Et tout les unix commerciaux.

              > faut se faire une raison sendmail est une merde bien bloat et pas secure.
              Ouais, je sais, c'est comme bind, etc... Je connais la rengaine...

              > REdhat fais une tres grosse erreur de le mettre par default
              La RH 6.2 a deux mises à jour de sendmail... Très couteux en maintenance !
              La RH 6.2 a cinq mises à jour linux pour sécurité.
              ......... trois mises à jour pour php
              ......... quatre pour apache
              ......... quatre pour openssl
              ......... trois pour squid
              ......... deux pour bind !

              Conclusion : bind et sendmail parmis les plus sûrs.

              Petites questions :
              à l'époque de la RH 6.2, qui proposait autre chose que sendmail ?
              Comment fait-on en 3 ans pour passer de logiciel respectable et utilisé par tout le monde en "daube".
              • [^] # Re: Faille de sécurité importante dans Sendmail

                Posté par  . Évalué à 3.

                Sendmail a pas su evoluer , fais joujoux avec exim ou postfix un jour en grandeur nature et tu comprendras.
                • [^] # Re: Faille de sécurité importante dans Sendmail

                  Posté par  . Évalué à 1.

                  Notes que je n'ai pas mis en cause postfix, exim etc... J'ai même dit que j'y connais rien en serveur mail. Mais j'aime pas ces attaques gratuites sur des programmes gratuits et qui ont rendu d'immence service au moins à une époque ou sendmail était la seule possibilité.
                  J'ai parlé de exim, utilisé par défaut sur Debian et je n'ai pas remis en cause leur choix.
                  Je ne dis jamais que sendmail est mieux que les autres :-)
                  Si on me dit que exim est meilleur que sendmail, j'ai aucun argument pour dire le contraire. Mais admettre que sendmail est une merde ... est un pas que ...
                  • [^] # Re: Faille de sécurité importante dans Sendmail

                    Posté par  . Évalué à 6.

                    Déjà il y a des différences de conception, Sendmail est monolithique et tourne en temps qu'user root alors que les autres non.
                    La modularité de Postfix permet par exemple de créer des plateformes mail avec un service par serveur ou ferme de serveur de façon simple et efficace qui permettront de mieux tenir la charge que sur un seul serveur (avec aussi la possiblité de tuner la ferme, c'est à dire plus de serveurs pour tel ou tel service etc...).

                    Peut être que je me trompe, mais tout ça n'est pas possible avec Sendmail... Ou tout du moins d'une façon moins simple.

                    De plus, le passage de Sendmail à Postfix se fait très facilement et rapidement grace à des fichier de configuration simple et performant. Alors que concernant l'inverse...
                  • [^] # Re: Faille de sécurité importante dans Sendmail

                    Posté par  (site web personnel) . Évalué à 4.

                    J'ai même dit que j'y connais rien en serveur mail. Mais j'aime pas ces attaques gratuites sur des programmes gratuits et qui ont rendu d'immence service au moins à une époque ou sendmail était la seule possibilité.

                    Ben écoute, si tu avoues ne rien y connaître, comment peux-tu affirmer qu'il s'agit là d'attaques gratuites ?

                    Et je crois qu'on a tous déjà utilisé (en tous cas c'est mon cas) un logiciel qui nous a rendu d'immenses services à un moment donné, sans que ça empêche de se rendre compte plus tard que ce logiciel était de piètre qualité, après avoir utilisé quelqus uns de ses concurrents. Refuser de réviser son jugement pour de bêtes raisons affectives est alors tout simplement ridicule.
                    • [^] # Re: Faille de sécurité importante dans Sendmail

                      Posté par  . Évalué à 3.

                      Tu sais lire ? Je m'interroge.

                      > qu'il s'agit là d'attaques gratuites ?

                      Relis. Je parle d'attaque sur le niveau de sécurité de sendmail et d'attaques qui dit en gros que sendmail c'est de la merde. Il y a quelques commentaires ici qui montrent que sendmail à des fonctionnalités "uniques". Comme les autres serveurs ont des approches interressantes et aussi surement des fonctionnalités que sendmail n'a pas.

                      > Refuser de réviser son jugement pour de bêtes raisons affectives est alors tout simplement ridicule.

                      Où vois-tu que je refuse d'utilise autre chose que sendmail ? Cites-moi !

                      Je n'ai pas dit que j'était attaché à sendmail, que si il me faut un serveur se sera sendmail car j'y suis attaché etc...
                      Relis.
                      A l'époque de la RH 6.2 on m'a demandé d'évaluer rapidement des serveurs mails. J'ai retenu sendmail et exim. sendmail car forte réputation et son côté "couteau-suisse". Malheureusement complexe. exim car GPL, plus simple et satisfesant pour la majorité et utilisé par Debian. C'était il y a 3/4 ans !

                      Enfin, mes choix ne sont pas disté par RedHat comme d'autres le sous-entendent. J'utilise depuis longtemps proftpd alors que la prochaine RedHat 8.1 ne le fournit toujours pas. J'utilise subversion alors que RedHat (comme les autres) fournit CVS, etc, etc...

                      Alors, SVP, lisez bien mes commentaires.
                      Ça devient lourd ces remarques depuis quelques mois alors qu'avant (durant au moins 4 ans) on me foutait la paix.

                      Merci pour moi. Paix sur vos couches.
              • [^] # Re: Faille de sécurité importante dans Sendmail

                Posté par  . Évalué à -3.

                > La RH 6.2 a cinq mises à jour linux pour sécurité.
                > ......... trois mises à jour pour php
                > ......... quatre pour apache
                > ......... quatre pour openssl
                > ......... trois pour squid
                > ......... deux pour bind !

                Encore un peu et on finirait pas croire que tu ferais un plaidoyer digne de Microsoft...
              • [^] # Re: Faille de sécurité importante dans Sendmail

                Posté par  (site web personnel) . Évalué à 0.

                Et tout les unix commerciaux.

                Ah, ah, ah !!! Quel humour. Ces mêmes unix commerciaux ont utilisé pendant des années CDE une merveille d'ergonomie et de fonctionnalité à la place de KDE ou gnome. Ils ont été livrés des années avec un compilateur totalement merdique, qui produisait du code moins bon que gcc (même si ce n'est pas toujours vrai), etc. Bref, cet argument d'autorité n'a aucune valeur.

                Quant à la comparaison en terme de nombres de bugs trouvés sur des applis qui n'ont aucun rapport en terme de fonctionnalité, c'est tout simplement grotesque.

                A l'époque de la RH 6.2, le site même de redhat.com utilisait qmail. Alors, je rigole.

                Comment fait-on en 3 ans pour passer de logiciel respectable et utilisé par tout le monde en "daube".

                Euh, windows ?
                • [^] # Re: Faille de sécurité importante dans Sendmail

                  Posté par  . Évalué à 4.

                  > A l'époque de la RH 6.2, le site même de redhat.com utilisait qmail. Alors, je rigole.

                  Et maintenant redhat.com utilise sendmail.
                • [^] # Re: Faille de sécurité importante dans Sendmail

                  Posté par  . Évalué à 0.

                  Ces mêmes unix commerciaux ont utilisé pendant des années CDE une merveille d'ergonomie et de fonctionnalité à la place de KDE ou gnome...
                  Quant les autres OS était encore à faire de l'ASCII art sur VT100

                  Ils ont été livrés des années avec un compilateur totalement merdique, qui produisait du code moins bon que gcc
                  La belle affaire... en attendant, il y a quelques années j'aurai aimé disposer d'un gcc pour compiler du C++ avec héritage multiple et classes abstraites ce que proposaient (de manière assez artisanale je le concède) les compilos SUN (Solaris) ou IBM (AIX)

                  En résumé, je pense qu'il te faudrait replacer chaque chose dans son contexte de l'époque et que les outils GNU d'aujourd'hui se sont (heureusement !) grandement améliorés...

                  Pour finir,
                  Euh, windows ?
                  Sans argumentation, nul et non avenu...

                  Et pour en revenir au compilo, désolé mais sur un projet C++/Corba/SGBD O² de plusieurs millions de lignes de code mon choix se porte/portait sur un compilo "spécifique à la plate-forme", Solaris/Intel en l'occurence... pas sur le gcc de l'époque...
                  (même si ce choix pourrait être remis en cause à l'heure actuelle)
                  • [^] # Re: Faille de sécurité importante dans Sendmail

                    Posté par  (site web personnel) . Évalué à 2.

                    Quant les autres OS était encore à faire de l'ASCII art sur VT100

                    Bien entendu, il est bien connu que CDE existait avant macintosh, qui d'ailleurs avait une interface ascii. Sauf qu'en 1991 par exemple, sun en était encore à sunview. Or, d'après http://www.hofstra.edu/Academics/HCLAS/CSC/ComputingHistory/CompHis(...) (par exemple), lisa date de 1983, le mac de 1984 et windows de 1985... Il est vrai que les premières GUI sont apparues dans le monde unix, mais de la à raconter n'importe quoi... D'ailleurs, vu que X date de 1984, je ne vois pas trop de quoi tu parles.

                    De plus, cela fait des années, disons au moins 3 que KDE offre plus de fonctionnalités que CDE et pourtant, toujours rien de la part de nos chers vieux UNIX

                    il y a quelques années j'aurai aimé disposer d'un gcc pour compiler du C++ avec héritage multiple et classes abstraites ce que proposaient (de manière assez artisanale je le concède) les compilos SUN (Solaris) ou IBM (AIX)

                    Soit tu te trompes, soit tu racontes n'importe quoi. J'ai commencé à coder pour ma thèse en C++ sur solaris en 1994 et je peux t'assurer que le meilleur support de la "norme" venait de gcc, qui proposait bien entendu héritage multiple, templates et classes abstraites. Il n'implémentait pas toute la norme, mais bon, c'était beaucoup mieux que le compilateur sun.
                • [^] # Re: Faille de sécurité importante dans Sendmail

                  Posté par  . Évalué à 9.

                  Les unix commerciaux ont été les modèles des progets GNU et Linux. D'ailleur GNU/Linux respecte pratiquement toute les normes Posix.

                  Le projet GNU doit beaucoup aux unix commerciaux. Car avant que Linux puisse exister, il fallait un compilo, un shell, etc. gcc, bash, binutils etc ont été développé sous les Unix commerciaux.

                  > CDE
                  Avant Gnome/KDE il fallait ce contenter de fvwm2 sous Linux et les unix commerciaux avait CDE.

                  > Euh, windows ?

                  Sendmail n'est pas propriétaire et respecte les standards. Mauvaise pioche.
                  • [^] # Re: Faille de sécurité importante dans Sendmail

                    Posté par  (site web personnel) . Évalué à 1.

                    Je n'ai jamais dit que les unix commerciaux n'avaient rien apporter à linux, loin s'en faut. Je dis simplement que l'argument selon lequel un unix commercial fait quelque chose, donc c'est bien est crétin.

                    Avant Gnome/KDE il fallait ce contenter de fvwm2 sous Linux et les unix commerciaux avait CDE.

                    Ouai, ba franchement, à l'époque je préférais fvwm2 à cette merde de CDE. De plus, ça fait des années de KDE fait mieux que CDE, mais alors des années !
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  . Évalué à 7.

            <i>> Sendmail est une merde.

            C'est évident. C'est même pour ça qu'il est le plus utilisé par les gros sites. C'est pour justifier les salaires des admins. C'est aussi pour ça qu'il est utilisé par tous les Unix commerciaux. C'est pour bien montrer que le free software c'est de la merde.

            Bah voui et comme Windows est l'os le plus utilisé c'est évident que c'est le mieux... :-)
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  . Évalué à 4.

          Pour le bug Postfix, je suppose que tu parles de celui-ci:
          http://www.securityfocus.com/archive/1/240354(...)

          Ce qui est marrant, c'est que l'auteur de Postfix affirme que le même bug existe dans qmail, sauf qu'il n'a jamais été corrigé.
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  . Évalué à 1.

          Il me semblait avoir lu quelque part (mais je ne sais plus où) que RedHat conservait Sendmail car ils estimaient que seul Sendmail pouvait gérer un TRÈS gros trafic de mail.
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  . Évalué à 1.

            c est quoi un gros traffic ? enfin bon y a des gros FAI qu on plutot l air de bien s en sortir sous postfix.
            • [^] # Re: Faille de sécurité importante dans Sendmail

              Posté par  (site web personnel) . Évalué à 1.


              > enfin bon y a des gros FAI qu on plutot l air de bien s en sortir sous postfix.


              Dans ce sens là, à mon avis, un gros traffic, c'est plusieurs centaines ou milliers de messages pour un même domaine. Certains FAI sont sous Postfix mais se gardent quelques sendmail dans un coin pour pouvoir gérer des domaines boulets qui pourront refiler tous les mails pour le domaine en un minimum de connexions, contrairement à Postfix.

              seb.
              • [^] # Re: Faille de sécurité importante dans Sendmail

                Posté par  . Évalué à 1.

                Dans ce sens là, à mon avis, un gros traffic, c'est plusieurs centaines ou milliers de messages pour un même domaine.
                Postfix le gére absolument sans problèmes et même mieux a mon avis (humble) que Sendmail.

                Certains FAI sont sous Postfix mais se gardent quelques sendmail dans un coin pour pouvoir gérer des domaines boulets qui pourront refiler tous les mails pour le domaine en un minimum de connexions, contrairement à Postfix.
                J'avous ne pas trop saisir... Si tu parle des bounces, peut importe que ce soit du Sendmail ou du Postfix ou Exim ou Qmail... Et je ne comprend pas trop en quoi Sendmail pourrait refiler des mails en moins de connections qu'un Postfix...
              • [^] # Re: Faille de sécurité importante dans Sendmail

                Posté par  . Évalué à 0.

                Dans ce sens là, à mon avis, un gros traffic, c'est plusieurs centaines ou milliers de messages pour un même domaine.

                bin ca tombe bien , moi c est ~150K mails/jour et postfix s en sort tres bien
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  (site web personnel) . Évalué à 2.

            Ben, c'est pas pour troller (enfin bon, au point où on est :-) mais apparemment y a des gens pour qui Sendmail ne tient pas suffisamment bien la charge. D'ailleurs, ils ont créé un MTA ad hoc : ZMailer. Ils expliquent le pourquoi du comment à [http://zmailer.org/overview.html(...)]. Quant à savoir ce qu'il en est réellement, bah c'est moins évident. Quelqu'un saurait s'il y a déjà eu des benchmarks de faits (juste par curiosité parce que les quelques centaines d'utilisateurs ici ne nécessitent pas de se poser de pareilles questions, heureusement pour moi :-) ?

            Envoyé depuis mon PDP 11/70

          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  . Évalué à 3.

            Il me semblait avoir lu quelque part (mais je ne sais plus où) que RedHat conservait Sendmail car ils estimaient que seul Sendmail pouvait gérer un TRÈS gros trafic de mail.

            Red Hat utilise Postfix en interne.
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  . Évalué à 2.

          >Sendmail est une merde.

          Faut pas pousser non plus. je l'utilise depuis maintenant 6 ans... C'est sur il y a des bugs comme dans tout logiciel. Maintenant c'est aussi au n-user de remonter les bugs et de participer à l'amélioration du produit.

          Chacun étant libre de choisir ce qu'il veut, perso sendmail a toujours répondu à ce que je cherchais à faire... ( sql y compris les patchs existent pour mysql, postgresql, ... les posts de Andrzej Filip et de Claus Aßmann sur comp.mail.sendmail sont là aussi pour aider l'admin débutant ( le confirmé aussi d'ailleurs ;-) ) sur sendmail... on trouve déjà énormément de .mc ou de hacks pour faire tout et n'importe quoi avec sendmail et la libmilter permet de faire ses propres filtres en un rien de temps c'est assez géant... ).

          Quand au sendmail.cf, c'est vrai qu'au début, ça peut faire peur, mais bon c'est comme tout, il faut s'y mettre... Après quelques essais et une lecture attentive du gros bouquin à la chauve souris ( 3ième édition ), ça en devient presque facile... ( j'ai bien dit "presque" ).

          Maintenant des alternatives existent ce n'est pas plus mal... Je ne connais pas assez les autres pour en parler, je regarderai quand j'aurai plus de temps mais bon sendmail est quand mm pas si mal que ça !

          Si vraiment c'était un si mauvais produit que ça, est-ce qu'il serait
          toujours là aujourd'hui ??? ( troll'ing time... ;-) ).
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  . Évalué à 1.

            Oui certe Sendmail est puissant, robuste et étant donné que beaucoup de gens l'utilise il doit y avoir un très grand support de celui ci ainsi qu'un large panel de patchs disponible.
            Cependant, quitte à choisir entre un logiciel on il faudra 2 semaines acharné pour savoir le configurer (mais pas le maitriser) et un autre plus simple, avec les mêmes fonctionnalité, moi personnellement je choisi le 2nd... Il y a tellement de logiciel libre et de doc à potasser, qu'il est inutile de perdre son temps à vouloir s'acharner à en conprendre un...
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  . Évalué à 10.

          Trop, c'est trop

          Pour répondre de manière générale à un peu tous les posts:

          La première version de sendmail a 20 ans : 1983 dans BSD 4.1c (y en a un paquet ici qui étaient encore en couche culote et surement les plus virulents).
          A l'époque, TCP/IP avait officiellement 1 ans d'existance en prod sur ARPANET.
          A l'époque, et jusque dans les années 95, un relais de SMTP etait "ouvert" par définition.
          Et on pourrait contiuer longtemps comme ca...
          Bon, ca n'excuse rien mais:
          Sendmail n'est aujourd'hui pas plus troué qu'un autre MTA (c'est rigolo comme les releases de postfix passent inapercu ....) même si il a un très lourd passif.
          Sendmail a beacoup évolué et n'est plus aussi monolitique que l'on veut le laisser croire.
          Sendmail malgès sa très grande flexibilité et sa très grande finesse de configuration n'est pas compliqué a configurer. Par contre celui qui tripote à la main son sendmail.cf est un abruti. (a moins d'écrire le m4 qui va bien) Dans sa lente, progressive mais sure évolution, le fichier de conf sendmail.cf est aujourd'hui a considerer comme un fichier de conf interne auquel on ne doit pas toucher...
          ca c'est un fichier de conf par exemple :
          define(`confDEF_USER_ID',``8:12'')dnl
          OSTYPE(`linux')dnl
          DOMAIN(`generic')dnl
          define(`confTRY_NULL_MX_LIST',true)dnl
          define(`confDONT_PROBE_INTERFACES',true)dnl
          define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl
          define(`LOCAL_MAILER_FLAGS', `ShPfn')dnl
          define(`LOCAL_MAILER_ARGS', `procmail -a $h -d $u')dnl
          FEATURE(`smrsh',`/usr/sbin/smrsh')dnl
          FEATURE(`mailertable')dnl
          FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable')dnl
          FEATURE(`redirect')dnl
          FEATURE(`always_add_domain')dnl
          FEATURE(`use_cw_file')dnl
          FEATURE(`local_procmail')dnl
          FEATURE(`access_db')dnl
          FEATURE(`blacklist_recipients')dnl
          FEATURE(`dnsbl')dnl
          MAILER(`local')dnl
          MAILER(`smtp')dnl
          MAILER(`procmail')dnl
          Si ca c'est compliqué... (et encore, il l'est...)
          Pour les utilisateurs de Debian, jeter un coup d'oeil au package Debian (http://packages.debian.org/unstable/mail/sendmail.html(...)), il est tout simplement génial.

          En terme de fonctionnalité, Sendmail est quasiment toujour le premier à implémenter les dernières RFC (même si historiquement, il a eu fait de grosses disgression).
          Qu'on me parle pas du support LDAP de Postfix (MTA que j'aime beacoup par ailleur), les concepteurs de LDAP doivent être dégoutés, pourquoi se faire chier, rsh+grep dans un fichier à plat aurait fait aussi bien... C'est valable pour toutes les sources de data Postfix, c'est "élégant" a utiliser, mais c'est carément primitif en terme d'inplémentation et d'efficacité.
          Ok, simple, robuste... mais dans ces cas la je ne connais pas plus simple et robuste que la bonne vielle feille de papier et le stylo...
          Certe Postfix est plus "scalable" que Sendmail (et encore, si celui ci est mal configuré) à l'exeption près évoqué ci dessus, mais l'overhead de base est carement plus important pour une machine non dédié à du routage de courrier.

          Bon, je m'arrête là. En conclusion:
          Oui, Sendmail a un lourd historique qui ne lui donne pas une bonne image.
          Oui, de part d'autres aspects de ce même historique, Sendmail mérite le respect.
          Oui, Sendmail est a la pointe des RFC et a une liste de fonctionalités impressionantes.
          Non, Sendmail n'est pas aujourd'hui plus troué que les autres.
          Non, Sendmail n'est pas un enorme tas de code décrépit et pourri.
          Oui, Sendmail évolu progressivement et toujour dans le bon sens.
          Oui, l'évolution est lente, mais le passif et lourd et les compromis évolution / compatibilité / new feature / cleanup / rewrite sont toujour difficiles a faire.
          Oui, Sendmail est performant et avec un faible overhead de départ.
          Oui, Sendmail est simple a configurer mais est extrèmement flexible.
          Oui Sendmail est compliqué dans les config bien tordu. mais a config tordue conf tordue.

          Oui, Postfix rulez, mais Postfix Rulez <> Sendmail pourri.
          Oui, Postfix souvent plus simple.
          Oui Postfix extrèmement scalable, mais aussi plus gourmant de base.
          Oui Postfix ridicule sur certains points, mais Postfix jeune.
          Oui Postfix beton sur d'autres points, mais Postfix a été écrit avec des données de départ toutes autres, Postfix jeune.

          /Mode pétage de pomb on
          Oui, certains trolleurs boutoneux feraient mieux de fermer leurs gueules quand ils ne savent pas de quoi ils parlent.
          (Valable pour beaucoup d'autres sujets).
          /Mode pétage de plombs off

          Quand aux choix des distribs, Oui c'est bien que ce ne soit pas nécessairement le MTA par défaut, il y a encore plus simple et plus léger. (d'ailleur ce n'est pas non plus Postfix par défault sur Debian ou Mandrake....).


          Un vieux con, pas si vieux pourtant, sniff.
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  . Évalué à 1.

            Ahhhhh.... ;o))
            Enfin un point de vue marqué qui ne se veut pas systématiquement consensuel ...
            Sur le point "trolleurs boutonneux qui feraient mieux de fermer leurs gueules quand ils ne savent pas de quoi ils parlent", je te rejoins entièrement à la nuance près (qui va dans ton sens d'ailleurs) que :
            the world's first "knowing" of linux; A 1991 post to comp.os.minix from Linus Torvalds. : en l'occurence, le monde n'a pas attendu cette date pour faire courrir les bits et allumer des pixels sur un écran....
            Tout cela pour dire que cette jeune génération (qualifiée plus prosaïquement de trolleurs boutonneux) a parfois tendance à réfléchir avec autre chose qu'avec le truc planqué entre ses deux oreilles sous prétexte d'avoir tapoter sur un clavier...

            Ce qui est bien dommage...
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  (site web personnel) . Évalué à 1.

            Merci pour le boutoneux. Si tu veux, on peut discuter technique aussi.

            Juste quelques remarques.

            1) va voir http://cr.yp.to/qmail.html(...) pour des mesures d'efficacité de qmail
            2) il y a eu 4 releases de qmail, dont aucune pour fixer un bug de sécurité
            3) cf http://cr.yp.to/surveys.html(...) pour des stats d'utilisation d'autre chose que qmail
            4) je suis presque sûr que postfix est par défaut dans Mandrake 9
            5) combien de bugs critiques dans sendmail (i.e., accès root distant) et combien de bugs critiques dans qmail et postfix ?
            6) je ne comprends rien à ton histoire de sources de données de postfix
            • [^] # Re: Faille de sécurité importante dans Sendmail

              Posté par  . Évalué à 3.

              Désolé,

              Je ne m'adressais pas a toi en particulier:
              Pour répondre de manière générale à un peu tous les posts:

              Tu remarquera que je n'ai pas critiqué Qmail.
              1- Maintenant si tu veur parler perf, faut voir les conditions de test.
              Ton Qmail avec une liaison satellite meme a haute vitesse (d'une manière générale, grande bande passante et forte latence), ben il va se vautrer par rapport à un Sendmail.
              voir:
              http://www.cs.helsinki.fi/linux/linux-kernel/2003-09/0002.html(...)

              2 - Qmail est un excelent mailer construit sur une base plus saine que sendmail et plus simple car il ne supporte pas tout. cf 1 et mon post precedent. Faut pas me faire dire ce que je n'ai pas dit :-)

              3 - Oui et alors ? Sendmail est toujour majoritaire, l'est historiquement parcequ'il était un peut tout seul avant... il y a moins de 10 ans tu demandais à qq'un ce q'était Internet il t'aurait répondu kezako ? Y avait pas beaucoup de personnes non plus avec des serveur mail sous win3.11 ou 3.51 .... Ajoud'hui le reste du parc dans les stats c'est du MS ou de la gateway antivirale...
              Qmail est troisième cool. A mon avis dans des stats plus récentes postfix aurra progresse.

              4 - Je pensait que c'etait Qmail. Certe.

              5 - Combien de bug critiques dans sendmail dans des cas de config ultra tordu "que de toute manière les zautres savent pas faire donc risquent rien...." Bon, cette fois il est plustot balaize mais très objectivement ca arrive si souvent que ca ????

              6 - je parlais de l'accès au map alias, mbox, mailserver etc... ou ce que tu voudra, dans du LDAP, SQL etc...
              Quand je vois comment c'est fait dans postfix pour le LDAP, plustot que de me faire chier a mettre en place un serveur LDAP et ce que ca implique, autant appeler un grep en rsh dans un fichier localisé sur un serveur précis pour faire mes résolutions, ca sera aussi efficace.
              C'était juste histoire de dire un peut méchament que le support LDAP dans postfix laisse un peut a désirer et est franchement sous optimal par rapport aux capacités/fonctionnalites de LDAP.
              • [^] # Re: Faille de sécurité importante dans Sendmail

                Posté par  . Évalué à 1.

                4 - Je pensait que c'etait Qmail. Certe.

                Ouupps, je voulais dire exim.

                bref, un autre que satanmail euuuu sendmail.
              • [^] # Re: Faille de sécurité importante dans Sendmail

                Posté par  (site web personnel) . Évalué à 0.

                1) en effet. Certains tests semblent prouver que qmail charge aussi à mort le sous-système disque alors que postfix charge plutôt le CPU.

                5) ouai, pas très convainquant. L'aspect monolythique de sendmail est quand une source de gros problèmes....

                6) d'accord. Parce que postfix supporte des formats très efficaces pour stocker des maps (genre hash, arbre, etc.), donc je ne comprenais pas trop.
      • [^] # Re: Faille de sécurité importante dans Sendmail

        Posté par  . Évalué à 10.

        c est tres simple postfix est

        1/ plus performant ( cf caramail qui est passé de sendmail -> postfix , meme si maintenant c est encore devenu la catastrophe )

        2/ plus secure , suffit de regarder son fonctionnement , chaque tache est bien separée ( smtp , rewrite , spool ... ) et chacun dans son ptit chroot , que du bonheur

        3/ BEAUCOUP plus simple et logique a configurer ( moins on en met plus c' est secure )

        il ya vraiment aucune raison d utiliser sendmail , ou alors dans des trucs tres tres particuliers .
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  . Évalué à 2.

          Je cherche un serveur SMTP capable de faire de l'ODMR (rfc2645).
          Je n'ai trouvé qu"un truc qui tourne en companie de sendmail, et c'est seulement dans les wish list des autres ...

          quelqu'un pour me conseiller ?
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  . Évalué à 4.

          il ya vraiment aucune raison d utiliser sendmail , ou alors dans des trucs tres tres particuliers .

          Bon ben puisqu'on nage dedans, une serie de petite questions amusantes :
          - Comment on fait sous Postfix pour synchroniser une base IMAP avec une base mail NOTES ?
          - Est-ce que Postfix permet de gerer en natif des tuyeaux POP2/POP3/IMAP/TALK ?
          - Peut-on avec Postfix faire du controle / strip de header a la volee pour le relaying transparent de mails internes vers l'exterieur.
          - Est ce qu'il est facile de configurer Postfix pour faire du load balancing ?
          - Postfix possede-t-il un mode natif de gestion/processing du catch-all, des mailing listes ?

          Je ne connais pas les reponses, si c'est le cas je me pencherais sur cette solution. En attendant je ne sais pas ce que tu entends par "truc tres tres particulier" mais dans la pratique je n'ai jamais vu autre chose que sendmail (et exchange ARRGHH!) etre installe en tant que solution professionelle. C'est peut-etre du a des habitudes antediluviennes, mais je pense que ca repose plus sur le fait que Send mail est un outil d'une flexibilite hallucinante.

          Kha
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  . Évalué à 8.

            >>- Comment on fait sous Postfix pour synchroniser une base IMAP avec une base mail NOTES ?

            Avec un MDA peut être, j'ai pas notes.

            >>- Est-ce que Postfix permet de gerer en natif des tuyeaux POP2/POP3/IMAP/TALK ?

            C'est le boulot d'un MDA ça

            >>- Peut-on avec Postfix faire du controle / strip de header a la volee pour le relaying transparent de mails internes vers l'exterieur.

            Hein ?
            Pour un proxy transparent : oui
            Pour manipuler les entêtes (virer les hosts internes par exemple) : oui
            Pour les autres, précise ta pensé ;)

            >>- Est ce qu'il est facile de configurer Postfix pour faire du load balancing ?

            J'ai 3 MX pour l'extérieur, et 1 seul en interne car j'arrive jamais à le mettre par terre.

            >>- Postfix possede-t-il un mode natif de gestion/processing du catch-all, des mailing listes ?

            "canonical" pour le catch-all.
            Pour le ML, y'a des produits pour ça.
            • [^] # Re: Faille de sécurité importante dans Sendmail

              Posté par  . Évalué à -1.

              mairde grillaid

              -1
            • [^] # Re: Faille de sécurité importante dans Sendmail

              Posté par  . Évalué à 2.

              Avec un MDA peut être, j'ai pas notes.

              Faisable, mais pas evident. A moins de creer un agent note (ie un trigger/entree crontab pour ceux qui ne connaissent pas notes) qui va reemettre tous les mails recu et envoyees vers une autre adresse, ca oblige a fair eun paquet de controle. La double distribution n'est pas un probleme. Mais les envois Notes vers Notes (qui ne devraient jamais passer par un serveur SMTP) et la sauvegarde des mails envoyes est assez dure a gerer.

              C'est le boulot d'un MDA ça

              Pas vraiment, a moins de configurer ton MDA pour qu'il distribue le courrier vers un autre serveur qui va a son tour appeler un autre MDA, il est assez complexe de transformer une conversation talk en mail vers l'exterieur (N.B: oui je sais copier-coller marche). De meme un utilisateur qui possede un portable sera vachement content de pouvoir recevoir ses mails en POP3 quand il se deplace, alors que si il est au bureau il appreciera d'avoir tout dans son IMAP (sans que son compte POP3 ne gonfle et qu'il est a se farcir 2000 mails en download la prochaine fois qu'il est en deplacement). Mais je sais aussi que je me sert tres mal de Procmail. Il y a peut-etre moyen de faire plus simple.

              Hein ?
              Pour un proxy transparent : oui
              Pour manipuler les entêtes (virer les hosts internes par exemple) : oui
              Pour les autres, précise ta pensé ;)


              Je pensais effectivement a un proxy transparent et a un masquage des etapes internes (ie un mail qui a tourne 2 jours en interne avant d'etre envoye vers l'exterieur). De meme que certaines adresses emails disparaissent de l'entete a moins que ce soit un message direct (ie PDG-> vers Mr X OK, PDG->secretaire-> Mr X apparait comme secretaire -> Mr X). Plus notemment un certain nombre de truc drole avec les headers Notes, quand le mail n'est pas imprimable/copiable.

              "canonical" pour le catch-all.
              Pour le ML, y'a des produits pour ça.


              J'utilise mon catch-all de la facon suivante. Quand je dois (ou un utilisateur dois) s'inscrire sur un site qui exige une adresse email. Je file une adresse du type "nospamlesite@maboite.ext". Donc si mon catch-all recoit du spam, je cree une regle qui ferme la connection pour nospamlesite@maboite.ext juste au moment du to : . Avec Procmail on peut faire ce genre de chose, mais generalement on a deja telecharge le mail, et moi j'aime bien ma bande passante.

              Pour les ML j'utilise Majordomo, mais j'aime bien m'en servir avec Sendmail car il ya une foule de facon de l'integrer. Je pense que tout doit etre faisable autrement, mais par exemple quand un doc de 80 Meg passe sur une ML, j'aime bien savoir qu'il ne transitera qu'une seule fois, et etre sur qu'il n'y aura pas x copies pour les x abonnees de la ML.

              Ceci etant je vais me pencher sur les solutions alternatives a Sendmail (que j'avoue ne pas connaitre du tout(les solutions alternatives hein, pas de citations morceles de cette phrase)) et voir dans quelles mesures j'y gagne.

              Kha
              • [^] # Re: Faille de sécurité importante dans Sendmail

                Posté par  . Évalué à 1.

                Maintenant que la vague de [+/-] a passé, on va pouvoir causser tranquille :

                [syncrho entre imap et notes]
                J'ai menti quand j'ai dit que j'ai pas de notes : j'en ai bien un mais j'ai réfusé depuis le début que mes machines acceptent le moindre paquet avec l'adresse MAC gravée dan le marbre, et finalement je pense que j'ai bien fait. Tout ça pour dire que je refuse de faire le moindre effort vis à vis de notes "en tant que MTA", et c'est pas demain que je vais commencer.

                [passer des messages entre plusieurs serveurs]
                >>a moins de configurer ton MDA pour qu'il distribue le courrier vers un autre serveur qui va a son tour appeler un autre MDA

                Pas obligatoirement, y'a des trucs comme UUCP, NFS, OpenAFS ou même samba. A partir du moment qu'un message arrive quelque part, d'une façon ou l'autre, c'est justement à l'autre receveur d'en prendre soin, point barre.

                >>Je pensais effectivement a un proxy transparent et a un masquage des etapes internes
                Pour le proxy transparent, y'a pas grande chose à dire, ça marche toute seule.
                Pour le "masquage des étapes internes", je vois deux choses :

                Suppression des entêtes, avec postfix toujours :
                /etc/postfix/main.cf : header_checks = regexp:/etc/postfix/header_checks
                /etc/postfix/header_checks : /^Received: from/ IGNORE
                (assurez vous d'un bon log avant qu'un mec en interne se met à déconner)

                Ajout des entêtes, ça peut se faire avec (pas testé) un bon gros "content filter" au milieux, cherche sur google ou postfix-user "perl content filter disclamer" doit donner un bon résultat.

                Je pense néanmoins que c'est une mauvaise solution à une bonne question : chaque user doit assumer leur identité, et on doit leur aider avec des solutions appropriérées, mais pas en bidouillant leurs entêtres, sans leur consentement.

                Pour la boite anti-spam, je ne peux que conseiller une bonne adresse, (bon d'accord c'est propre à OpenBSD, mais bon, y'avait aussi, de mon temps, un VaxKiller ;) :

                http://www.benzedrine.cx/relaydb.html(...)

                Et une bonne nouvelle pour terminer, toujours sur le même site (y'a que du bon, je vous dis), à propos de QoS sur une ligne ADSL "simple" (512/128) :

                http://www.benzedrine.cx/ackpri.html(...)
                • [^] # Re: Faille de sécurité importante dans Sendmail

                  Posté par  . Évalué à 3.

                  Je pense néanmoins que c'est une mauvaise solution à une bonne question : chaque user doit assumer leur identité, et on doit leur aider avec des solutions appropriérées, mais pas en bidouillant leurs entêtres, sans leur consentement. La on est completement d'accord. Mais je ne me vois pas aller trouver la plupart de mes utilisateur pour leur demander si ils trouvent que ma politique est la bonne. Mon soucis est juste d'eviter 1) - que certaines adresse email sensibles ne se retrouvent a l'exterieur par erreur (ie sans que la personne sache que son email est sorti de la boite) 2) - Qu'un client qui recoit juste une bonne blague (aha) par email ne possede au passage d'integralite du carnet d'adresse de la boite.(on a eu ca, c'est pas beau a voir apres : vendeurs et commerciaux qui se fichent sur la geule en s'accusant mutuellement de se voler des clients). Donc plutot que de donner des cours de nettiquette et de responsabilisation vis a vis des systemes informatiques a toute la boite (ce que l'equipe ethique fait tres bien de son cote d'ailleurs) je verrouille. Mais je prie aussi pour avoir des utilisateurs responsables qui ne m'obligeraient pas a recourir a ce genre de manips. Kha P.S merci pour les liens, la plateforme de test Postfix se monte lentement.
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  . Évalué à 5.

            Comment on fait sous Postfix pour synchroniser une base IMAP avec une base mail NOTES
            faudrait peut voir ca du coté de ce qui gere l imap ( courrier , cyrus ... ) non ?

            Est-ce que Postfix permet de gerer en natif des tuyeaux POP2/POP3/IMAP/TALK

            pareil qu au dessus ( avec ipop3d et autres )

            Peut-on avec Postfix faire du controle / strip de header a la volee pour le relaying transparent de mails internes vers l'exterieur.

            tu parles de de la table transport ? ( genre tel from/to foo.tld -> tel smtp )
            du rewrite d entete ?

            Est ce qu'il est facile de configurer Postfix pour faire du load balancing

            Quel type de loadbalancing ( hashing , round robin , least connections , backup ... ) ? pour ma part j ai des alteons devant des doublons de postfix en hashing et ca marche impec.

            Postfix possede-t-il un mode natif de gestion/processing du catch-all, des mailing listes

            pour le catch all canonical , pour ce qui est des mailings listes je prefere le laisser a sympa ou mailman
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  . Évalué à 5.

            Bon ben puisqu'on nage dedans, une serie de petite questions amusantes :

            Pas sûr que le commun des mortels ait besoin de trucs aussi pointus, et ça doit limiter d'autant les gens qui savent faire, quel que soit le serveur mail utilisé...

            - Peut-on avec Postfix faire du controle / strip de header a la volee pour le relaying transparent de mails internes vers l'exterieur.

            Certainement, au pire en faisant tourner deux smtpd, éventuellement sur la même machine (c'est prévu, c'est notamment une solution pour intercaler un anti-virus), le point délicat étant de ne transformer les headers que pour les mails qui sortent, si c'est ce que tu cherches.

            Pour le problème classique d'adresses sur un serveur externe avec le nom de domaine du FAI ou avec un nom de domaine partagé par plusieurs sites, j'en étais arrivé à la conclusion que le plus simple, aussi bien pour l'utilisation que pour la configuration du serveur, était d'utiliser en interne les adresses externes et de délivrer directement les mails à ces adresses en interne, sans les laisser sortir, plutôt que d'utiliser des adresses internes spécifiques et de les remapper dans les mails qui sortent.
            Sous Postfix, il suffit de les déclarer dans une table "virtual" avec les noms d'utilisateurs locaux correspondants, et ça n'empêche pas de laisser sortir les autres adresses du même domaine (il suffit d'omettre la ligne avec un joker qu'on ajoute typiquement pour attraper tous les mails destinés à ce domaine).

            - Est ce qu'il est facile de configurer Postfix pour faire du load balancing ?

            Pas la moindre idée, mais du fait de ses performances, le nombre de sites qui auront besoin de faire du load balancing seront encore plus réduits qu'avec sendmail.
            Pour info, Free utilise Postfix, au moins en frontend. Certaines traces donnent à penser qu'ils utilisent Qmail sur des serveurs internes. Mais apparemment pas sendmail...

            Quant aux autres questions, faute d'avoir eu de tels besoins, je n'en ai pas la moindre idée...
            Globalement, ce sont des besoins que je rangerais dans la catégorie des "trucs très particuliers" mentionnée par houplaboom.

            Pour mes besoins, d'une complexité moindre, (par exemple, servir plusieurs domaines avec un masquerading correct), Postfix suffit largement et est bien plus simple à configurer que sendmail (je l'utilisais avant).

            Pour des besoins très pointus, c'est sûr que si tu maîtrises parfaitement la configuration de sendmail (je parle bien sûr du format de base, pas des macros et encore moins d'un frontend graphique), le choix paraît clair.
            Pour ma part, si j'ai un jour un besoin non satisfait par Postfix, je pense que j'aurais aussi vite fait de coder le bout qui manque en C que de le faire dans le format infâme du fichier de configuration de sendmail...

            Send mail est un outil d'une flexibilite hallucinante.

            C'est le mot : la dernière fois (dans tous les sens du terme) où j'ai essayé de configurer pour Sendmail un truc non supporté par les macros, j'en suis ressorti halluciné, pire que le jour où j'avais modifié le calcul des marges d'a2ps, codé directement en Postscript... ;-)

            « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  (site web personnel) . Évalué à 0.

            dans la pratique je n'ai jamais vu autre chose que sendmail (et exchange ARRGHH!) etre installe en tant que solution professionelle

            Regardes donc http://cr.yp.to/surveys.html(...) ...
    • [^] # Re: Faille de sécurité importante dans Sendmail

      Posté par  . Évalué à 8.

      Exim. http://www.exim.org/(...)
      Il est libre (GPL), incroyablement flexible, a une gestion hyper fine des droits, a un fichier de conf très clair, tient très bien la montée en charge.
      Bref, que du bon. (Je ne m'explique pas pourquoi il est aussi peu connu.)
    • [^] # Re: Faille de sécurité importante dans Sendmail

      Posté par  (site web personnel) . Évalué à 2.

      Au fait y'a quoi comme server de mail autre que Sendmail et Postfix?

      Je viens de découvrir Courier (http://www.courier-mta.org/(...) ).
      Pas encore essayer, mais ça a l'air pas mal!
  • # Re: Faille de sécurité importante dans Sendmail

    Posté par  . Évalué à 1.

    Suse aussi, dispo depuis 18:55 sur leurs ftp
  • # Pour ne plus avoir de problème avec sendmail

    Posté par  . Évalué à -3.

    cd /usr/ports/mail/postfix/stable && make && make install

    Voila, c'est pas compliqué.
    • [^] # Re: Pour ne plus avoir de problème avec sendmail

      Posté par  . Évalué à -3.

      sous gentoo/linux:
      emerge postfix

      mais moi c'est la version du commentaire du dessus que j'ai utilisée parce que j'ai un openbsd.
      J'ai un annuaire ldap aussi pour le fun qui danse avec postfix. Ils dansent bien, je vous assure surtout que le musicien est bon.
      ça fait un an que ça tourne. J'espère qu'ils survivront au désamorçage de bombe demain (voir mon site).

      et puis un coup d'oeil à la doc, c'est pas fait pour les chiens non plus.
      Oui parce que beaucoup pense que ça marche comme ça. Il y a un minimum à faire quand même, c'est de lire la doc.

      voilà.
  • # Re: Faille de sécurité importante dans Sendmail

    Posté par  . Évalué à 10.

    > NdM: Encore un buffer overflow dans Sendmail.

    C'est les programmes les plus utilisés qui sont le plus audité. Et c'est les programme les plus complexe/puissant qui sont le plus sujet au trou de sécurité. Rien de nouveau.

    Sinon, faut pas psychoter, d'après redhat, la faille est difficile à exploiter. Mais c'est pas une raison pour trainer :-)
    • [^] # Re: Faille de sécurité importante dans Sendmail

      Posté par  (site web personnel) . Évalué à 3.

      Ouai. Encore un argument facile pour se protéger des critiques portant sur une conception déplorable. Comme le disais ce cher pappy dans une autre news, la sécurité doit être au centre de la conception, pas rajoutée après. A mort sendmail (et bind aussi, d'ailleurs).
      • [^] # Re: Faille de sécurité importante dans Sendmail

        Posté par  . Évalué à 4.

        Pour Sendmail, c'est facile, y'a Postfix (voire exim ou qmail), mais pour Bind ? Maradns est sympa, mais y'avait des petits bugs vraiment chiants dans la résolution récursive quand je l'ai testé y'a qqs mois, peut-etre corrigés. Mais sinon ? Quelles alternatives ?
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  (site web personnel) . Évalué à 7.

          Je dirais PowerDNS [http://powerdns.com/(...)] ou MyDNS [http://mydns.bboy.net/(...)] pour la résolution autoritaire, et peut-être [http://home.t-online.de/home/Moestl/(...)] pour la résolution récursive (d'après les gourous, il vaut mieux séparer les deux). Tu peux aussi aller voir la page de DJ « mon égo est plus gros que le votre » Bernstein qui en cite plusieurs autres, en mettant bien l'accent sur tous les bugs de BIND [http://cr.yp.to/djbdns/other.html(...)]. Je n'ai pas essayé ses logiciels (djbdns, dnscache, etc.) parce que la licence m'ennuie, mais sinon ils ont plutôt bonne réputation...

          Envoyé depuis mon PDP 11/70

        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  . Évalué à 2.

          Quelles alternatives ? [ à Bind ]

          Peut-être DjbDNS, un serveur DNS fait par Daniel Bernstein (auteur de QMail), donc sans doute très sûr. Mais je crois qu'il ne fait pas tout ce que fait Bind.
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  . Évalué à 5.

          > Mais sinon ? Quelles alternatives ?
          L'alternative pour l'alternative...

          La première question est pourquoi prendre quelque chose d'alternatif. Si c'est pour des raisons de sécurité, bind est fort correcte ses dernières années et comme le dit matiasf plus haut, meilleur que beaucoup d'autres projets. Si c'est pour d'autres raisons... pourquoi pas.
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  . Évalué à 1.

          Contrairement à Sendmail, Bind est toujours chrootable et peut meme etre lance sous un autre utilisateur que root...
          S'il sagit des raisons invoquées pour le passage de Sendmail à Postfix/QMail/Exim/whatever, alors la comparaison ne tient pas énormément pour Bind: le projet évolue ! Preuve en est qu'un support des SGBDR et LDAP est en cours de développement et qu'il dispose de fonctionnalités assez pratiques qui manquent chez ses concurrents. Quant au load-balancing, l'ISC conseille lbnamed, un démon écrit spécialement pour l'usage en Perl...
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  (site web personnel) . Évalué à 1.

            Ma comparaison tenait plus de la provocation. Ceci étant, il y a quand même de choses troublantes dans bind. Par exemple, l'architecture aurait été totalement changée entre la version 4.x et la version 8.x (puis 9), pour des raisons de sécurité. Or, certains bugs de sécurité de 8.x se retrouvent (avec les mêmes erreurs de conception) dans 4.x (je n'ai pas les exemples en tête, je ne fais que répéter des rants de bernstein). Je suis d'ailleurs d'accord avec toi sur les fonctionnalités, bind en supporte énormément qui n'existent pas dans les alternatives...
    • [^] # Re: Faille de sécurité importante dans Sendmail

      Posté par  . Évalué à 3.

      d'après redhat, la faille est difficile à exploiter
      c'est marrant dans l' annonce de redhat sur bugtrack il n'y a rien de tel,
      et meme pire, redhat annonce qu'il y a un "proof of concept" mais qu'il
      n'a pas été diffusé ...

      bref exactement l'inverse de ce qui est écrit dans ton post ?!?
  • # Sécurité et réputation

    Posté par  . Évalué à 4.

    Salut à tous

    Je profite de la découverte de ce nouveau trou de sécurité pour me poser la question :

    Un certain nombre de logiciels comme sendmail, bind, wu-ftpd, etc, ont la réputation d'etre insécurisé. Et, de fait, il tombe plus ou moins régulièrement de nouvelles alertes à leur sujet.

    Qu'en est-il réellement ?
    Sécuriser un logiciel trainant une telle réputation revèle-t-il du domaine de l'impossible ?
    Est-ce un problème de conception, ces programmes n'ayant pas été pensé pour etre sécurisé dès le début ?

    Un poil qui dépasse ? De troll, en plus ? Voyons, où ça ? ;-)
    J'imagine que ça va troller, mais j'espère ne pas poser la question / ouvrir le débat en vain :)

    @+
    • [^] # Re: Sécurité et réputation

      Posté par  . Évalué à 3.

      > Qu'en est-il réellement ?
      Y en a qui ce font vite des idées. Sendmail, bind, wu-ftpd même s'ils ne sont pas parfaits sont très utilisés et ont largement démontrer leur fiabilité.
      Linux a largement collectionné plus de problème de sécurité que sendmail même en ne parlant que de la partie réseau. Pourtant tout le monde dit que Linux est sûr (ce que je pense aussi). Les autres produits sont plus récents et on logiquement un historique moins chargé. Mais la fréquence des trous de sécurité doit être la même. C'est le deux poids deux mesures en action. L'esprit rebelle qui aime attaquer les solutions établies parceque ce sont des rebelles.
      Bref, c'est que du pipo.
  • # Re: Faille de sécurité importante dans Sendmail

    Posté par  (site web personnel) . Évalué à 10.

    J'aimerais signaler un truc intéressant en marge de ce problème : ma boîte avait acheté il y a quelques éons un Sendmail-PRO (une version « améliorée » avec interface Web pour gérer le bordel) basé sur Sendmail/8.9.3 (que j'ai depuis bien longtemps remplacé par une version plus récente du Sendmail standard). Et aujourd'hui, on reçoit un e-mail de Sendmail, Inc. nous disant, en gros « houlàlà, on tient un gros problème là, faut que vous patchiez vite fait. En revanche, le produit que vous avez n'est plus supporté depuis des lustres, alors si vous voulez on vous propose une mise à jour gratos vers un de nos produits actuels, histoire que vous soyez protégés ». Et là, je dis chapeau, parce que rien ne les obligeait à faire ça. Imaginez un peu Microsoft vous disant « on a découvert un trou de sécurité qui affecte Windows NT 3.51. Comme il n'est plus supporté, on ne va pas le patcher, mais écrivez-nous et on vous enverra gratuitement une copie de Windows 2000 ». Impensable, hein ?

    Bref, bravo à Sendmail, leur attitude est très bonne sur ce coup (même si je me sens un peu hypocrite d'écrire ça alors que je fais tout pour éradiquer Sendmail de mes serveurs)...

    Envoyé depuis mon PDP 11/70

    • [^] # Re: Faille de sécurité importante dans Sendmail

      Posté par  . Évalué à 6.

      > alors que je fais tout pour éradiquer Sendmail de mes serveurs
      ...
      > alors si vous voulez on vous propose une mise à jour gratos vers un de nos produits actuels[...]

      Non non, quand on remet ton texte dans l'ordre on comprend tout de suite pourquoi ils font ça :)

      # sulfure has been kicked from linuxfr (trop con).
    • [^] # Re: Faille de sécurité importante dans Sendmail

      Posté par  . Évalué à 2.

      Oui, c'est vrai que c'est une attitude responsable (pour autant qu'ils n'y ait pas de nouveau trous béants dans la nouvelle version) ...

      Les constructeurs automobiles font aussi des rappels de leur anciens véhicules lorsque qu'une anomalie importante a été détectée. A l'heure où l'on voudrait faire passer les pirates informatiques pour des criminels de guerre, au regard du « danger extrême » qu'ils représentent, rares sont les grands éditeurs à faire preuve d'autant de véhémence (et surtout de méa culpa) lorsqu'il s'agit de combler les failles de leurs produits.

      Une fois que la news sera suffisament vieille pour que la plupart des serveurs aient été corrigés, il pourrait être intéressant de faire l'echo de ce genre d'initiative, histoire de donner l'exemple.
  • # Re: Faille de sécurité importante dans Sendmail

    Posté par  (site web personnel) . Évalué à 5.

    Effectivement, "buffer overflow" est devenu une news tellement banale...

    Je ne sais pas ce que sont ProPolice et StackGuard, mais je pense que le plus simple est quand même de privilégier des applis utilisant un langage de programmation qui empèche ce genre de faille (quand elles existent!).

    Le Secure Programming for Linux and Unix HOWTO (http://www.dwheeler.com/secure-programs(...)) a tout un chapitre sur ce sujet.
    Après avoir longement parlé de C/C++ (et justement de ProPolice et StackGuard), il termine par :

    The problem of buffer overflows is an excellent argument for using other programming languages such as Perl, Python, Java, and Ada95. After all, nearly all other programming languages used today (other than assembly language) protect against buffer overflows.

    Je sais bien qu'on ne fait pas toujours ce que l'on veut (le site de mon assoc http://www.ada-france.org/(...) doit bien tourner sur une machine à 95% avec des programmes en C alors qu'il fait la promotion du langage Ada).
    Mais bon, il faut quand même rappeller cette évidence de temps en temps, histoire que tout le monde soit conscient que le temps énorme que l'on perd sur ces stupidités est facile à éviter dés le début d'un projet.

    Lionel
    • [^] # Re: Faille de sécurité importante dans Sendmail

      Posté par  . Évalué à 6.

      C'est repousser le problème. On finit toujours par une fonction C. Ce qui compte c'est la réutilisation du code, diminuer le nombre de ligne de code pour que les audites soit efficace. Et php, perl, etc... ont aussi épisodiquement des trous de sécurité.
    • [^] # Re: Faille de sécurité importante dans Sendmail

      Posté par  . Évalué à 0.

      T'imagines sérieusement coder un serveur SMTP dans un autre langage que le C ??
      • [^] # Re: Faille de sécurité importante dans Sendmail

        Posté par  (site web personnel) . Évalué à 3.

        oui
      • [^] # Re: Faille de sécurité importante dans Sendmail

        Posté par  (site web personnel) . Évalué à 7.

        Mon trollomètre a frémis :-)
        Tu veux savoir si j'imagine d'utiliser un langage qui me permet de développer en 40% moins de temps avec 10 fois moins de défaut trouvé après release?
        Tu veux sérieusement que je réponde? :-)

        Je parle pour ce que je connais, Ada. Va voir dans http://libre.act-europe.fr/Software_Matters/(...) l'étude Ziegler dans Programming Languages and Software Construction.
        Maintenant si je dois développer un serveur SMTP from scratch sans Ada, et qu'on me prouve que Eiffel, Python ou le langage de la mére Denis présentent ne serais-ce qu'un quart de ces avantages, eh ben j'achète le Kernighan & Mère Denis et je m'y met.
        Parce que le soir, je préfère passer 1 heure avec mes enfants qu'avec gdb.

        Je sais, je sais, je ne suis décidement pas un vrai code warrior :-)
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  . Évalué à 1.

          Dans le cas d'une appli comme un serveur de mails, la performance (tenue à la montée en charge) est une priorité, donc faire ça en python, en perl ou autre, ça me fait bien rire.
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  (site web personnel) . Évalué à 2.

            Ta phrase commence raisonablement, mais derrière "ou autre" se cache un monde que tu ne sembles pas connaître. Ca n'a pas l'air de te géner pour lancer des phrases définitives.

            Il n'est bien sur pas question de Perl.
            Ada est un langage compilé. Ce qui fait la différence en terme de sécurité, c'est principalement la qualité de la conception du langage, et tout ce qu'il permet de vérifier à la compilation. Les (très utiles) checks ajouté à l'exécution peuvent être retirés par les options de compilation.
            Dans ce cas, tu ne perd rien en performance, mais tu gardes le bénefice des vérifications à la compilation.
            C'est probablement essentiellement la même chose pour Eiffel.
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  (site web personnel) . Évalué à 0.

          Ca fait du bien de lire des posts comme le tient. C'est quand même incroyable cette révérence obsolue pour le C qui serait le langage de la mort qui tue, alors que tout ce que langage tue, c'est bien les programmeurs. Depuis le temps qu'il existe des alternatives dans plein de domaines, chacune adaptée aux besoins du domaine, comme Ada, Eiffel, python, Java, et même C++, c'est incroyable de voir le nombre de développeurs qui continuent à ne jurer que par le C ! Quand je pense que le moteur de doom 3 est développé en C++ (autour de la partie openGL, hein, cf http://www.gamespy.com/e32002/pc/carmack/(...)), l'argument du développement d'un serveur SMTP obligatoirement en C, ça me fait plus que marrer. D'ailleurs en parlant de jeux, de nombreux hits récents sont écrits en C++ (cf http://www.research.att.com/~bs/applications.html(...)). Bref.
          • [^] # Re: Faille de sécurité importante dans Sendmail

            Posté par  . Évalué à 2.

            Aie aie aie,
            Je sens que ca derape alors j'arreterai là.
            C++, ben ouais réécrivons tout en C++, le kernel, la libc (plonk), après on ecrira des super outils de la mort qui tu pour profiler systematiquement tout ca étant donné qu'aubout d'un moment, n'étant même plus capable de savoir ce que fait réellement le code, ben faut tracer, analyser, bencher a la methode vodoo, j'ty rajoute un pti buffer de truc par ci et par la sinon mon bastringue fait houatmille millier d'intanciations allocation desalocation secondes et ca ramme, ca bouffe de la ram. puis derière j'ty pond deux trois script magiques pour analyser les sections de code générées pour voir pourquoi mon "hello world" genère un code objet de 20Mo et alloue 100Mo de ram en runtime, pius après je me rend compte que mes trois putains de classes X Y et Z ben c'est caca et je devrai avoir à la place un truc genre V W, mais la je remet pas en cause l'implementation de mes objets, mais l'ensemble de la conception parce que de toute manière je sais plus comment est branlé tout le reste vu qu'il me faudra au moins 3 mois pour retrouver comment mon truc U derive de mon machin T lui même hérité de ..... Bon un pti pointeur bien placé par là et hop le tour et joué et puis dans tout ce merdier bien opaque (c'est la philo du machin, c'est bien ) personne n'y vera que du feu...
            Merde, ca rame quand même sur ma machine ben oais, ca s'apelle Mozilla.
            Et puis tous les developpeurs windows font du C++ non ? Ben oui, c'est MSVC++ le non du compilo non ?
            Quand à Carmack, il a eu le temp de le paufiner son design avant de passer au c++, Doom1 doom2, Quake 1,2,3 bon je lui fait confiance pour passer au c++ maintenant, puis on peut pas, à lui, reprocher le fait qu'il code en ++ "parceque c'est un super language qui resoud même le fons du pblm à ta place". Tu chi de la déclaration, des classes, de l'objet et hop ca marche, sinon ben c'est pas ta faute, c'est le compilo, c'est l'os, ben coment tu gère le truc T et le machin M ? Ha, j'sais pas c'est l'objet O, quel boulet le développeur de O. Par contre le design D, ca personne connais, et le développement incrémental si cher a notre comunauté OpenSource ca marche pas bien avec ++ ? ben c'est que c'est de la merde alors.

            Alors bon, c'est sur Mozilla est en ++ et l'histoire nous a montré que du coup il n'avait jamais de trou de sécurité....

            A la vue de la pluspart (j'ai pas dit tous .... mais a tout bien réfléchi, presque) tes posts dans cette news, y a deux solutions: Soit ca te fait simplement tripper de foutre la merde et d'exiter les gens avec des propos gratuitements provocateurs et sans intérêts réels (un trollermaster ?), a mois que ce soit dans l'expectative de te recycler dans la socio (nouvelle thèse ?), ou alors on a affaire a qq'un du style des types qui viennent de découvrir l'informatique depuis moins de 2 ans et qui savent tout sans avoir jamais rien fait genre adolescent boutoneu. Vu la date de ta Thèse, je penche plustot pour la première solution.

            Sans rancune.

            Un vieux con qui pense très sérieusement se recycler très prochainement dans la plomberie/electricité/maconerie.
            • [^] # Re: Faille de sécurité importante dans Sendmail

              Posté par  . Évalué à 1.

              Bof, ce dont tu parles tient plus de la complexité d'une grosse application que de défauts liés au C++. Aux dernières nouvelles, comprendre comment tout fonctionne dans un programme en C de 80000 lignes n'est pas beaucoup plus simple et en C on trouve aussi des hacks immondes qui rendent le code encore moins clair.
              En gros tu prends des exemples où il y'a abus dans l'utilisation du C++ (on est pas obligé de faire du polymorphisme, ni de l'héritage multiple à chaque fois qu'on développe) et tu en déduis que le C++ est une merde. Conclusion tu agis de la même façon que ceux que tu entends dénoncer. Le C a plein de défauts (le passage par valeur par exemple ou bien les chaines de caractères) et des langages tels que l'Ada, Eiffel ou autres essayent d'apporter une réponse plus efficace, ce n'est pas plus mal.
              Au passage, je suis un jeune con qui code en C et en C++ et je pense (du moins j'espère) savoir aprécier les 2 langages à leur juste valeur.
            • [^] # Re: Faille de sécurité importante dans Sendmail

              Posté par  (site web personnel) . Évalué à 1.

              Un instant, j'ai cru en lisant tes précédents commentaires que tu t'étais vraiment énervé et donc un peu lâché. Et puis voilà que tu glisses de nouveau vers l'attaque personnelle à deux centimes. Ton rant sur le C++ est tout simplement incompréhensible et ridicule. Quant à ta tentative de psychanalyse à partir de mon CV (et oui, si quelque souhaite savoir qui est boubou, il lui suffit de suivre un lien), je ne sais de quel nom la qualifier.

              Je ne tenterais donc pas une discussion sur l'aspect technique puisque tu te discalifies d'entrée.

              Pour finir sur une attaque personnelle, ton auto-définition me semble parfaitement bien choisie. Enfin, pour le vieux, je ne sais pas.
              • [^] # Re: Faille de sécurité importante dans Sendmail

                Posté par  . Évalué à 1.

                Bravo mon cher Boubou: non content de dénigrer des programmes d'une manière facile, tu insultes les gens. Notes que si Emmanuel est un vieux con, je dois sans doute en être un aussi car j'ai exactement la même lecture que lui de tes différentes interventions et mis à part d'écrire que Sendmail est de la merde, je n'ai rien vu de bien constructif de ta part à la suite de cette news.

                Concernant Sendmail: je ne l'aime pas du tout et évite de l'utiliser lorsque c'est possible mais dans le même ordre d'idées, je n'aime pas Bernstein qui est suffisant et agressif. Manifestement, et pour avoir lu ses nombreux propos vénimeux sur Sendmail et Bind, tu te contentes de reprendre à ton compte ses avis et son ton. Je ne rentrerai pas dans le débat plus loin mais:
                -ce sont en effet les programmes les plus utilisés qui ont le plus de failles, c'est un fait et une explication, pas une excuse j'en conviens
                -pour me faire l'avocat du diable: j'ai un sendmail intégré à une distro d'un côté, de l'autre j'ai un qmail que je dois compiler (et patcher) pour le maintenir. Faire un rpm -i sendmail ou apt-get install sendmail même 2 fois par an à cause d'une faille est infiniment moins fastidieux que de patcher et recompiler qmail. Sur le plan pratique, ça ne tient donc pas.
                -la sécurité est un élément à remettre en cause en permanence et qmail n'est lui même absolument pas à l'abri d'une faille. King for a Day, Fool for a Lifetime!

                Par ailleurs:
                Boubou le 03/03:
                Ouai. Encore un argument facile pour se protéger des critiques portant sur une conception déplorable. Comme le disais ce cher pappy dans une autre news, la sécurité doit être au centre de la conception, pas rajoutée après. A mort sendmail (et bind aussi, d'ailleurs).

                Pappy le 28/02:
                Et puis, je ne comprends cette vision qui consiste à considérer la sécurité comme une espèce de truc bonus qu'on ajoute à la fin après tout le reste ... alors que c'est quand même plus facile, et souvent plus efficace, de l'intégrer directement dans le processus.

                Bref, tu ne fais qu'interprèter librement et radicaliser le discours de Pappy nettement moins péremptoire et plus réaliste. N'étant pas spécialiste de C++, je ne rentrerai pas dans le débat mais si ta lecture est aussi honnête intellectuellement que celle que tu viens de faire de l'avis de Pappy, tu me permettras de prendre tes remarques avec un certain recul.
                • [^] # Re: Faille de sécurité importante dans Sendmail

                  Posté par  (site web personnel) . Évalué à 1.

                  tu insultes les gens C'est exact. Après avoir subit certains trolleurs boutoneux feraient mieux de fermer leurs gueules quand ils ne savent pas de quoi ils parlent., puis une sorte de tentative de psycologie à deux sous basée sur mon CV, j'ai estimé justifié qu'Emmanuel s'auto qualifiait très bien. Puisque que tu as passé quelque temps à rechercher mes citations, tu remarqueras que je n'ai attaqué directement personne, contraitement à Emmanuel qui n'a fait que ça. Effectivement, j'ai relayé les propos aggressifs de Bernstein sur sendmail et Bind, mais non sans avoir passé pas mal de temps à chercher les opinions contraires et à lire avec applications les argumentations de Bernstein et de ses contradicteurs. D'autre part, j'ai pas mal travaillé en génie logiciel et ton petit laïus sur plus on teste, plus ou trouve de faille, et roi un jour, bouffon l'autre me laisse perplexe. Mon expérience est qu'un logiciel mal conçu (comme sendmail) comporte toujours plus de bugs qu'un logiciel bien conçu, et que le nombre de failles graves découvertes dans un logiciel est une bonne indication de la qualité de sa conception. Notes bien que ton argumentation sur sendmail et la facilité de le réinstaller tiens pour n'importe quel logiciel open source, en particulier postfix dont la conception est bien plus propre que celle de sendmail. Sinon, ne t'inquiètes pas pour pappy, je le connais personnellement depuis quelques années et je ne pense pas déformer le fond de sa pensée.
    • [^] # Re: Faille de sécurité importante dans Sendmail

      Posté par  . Évalué à 3.

      Note qu'il est possible de faire du C++ sans le moindre pointeur, ce qui permet d'avoir un bon compromis entre fiabilité et rapidité/utilisation des ressources. Pas de problème de buffer overflow quand on utilise string et vector.
    • [^] # Re: Faille de sécurité importante dans Sendmail

      Posté par  . Évalué à 2.

      En parlant de langages alternatifs au C, j'ai eu récemment à écrire un algorithme, et comme mon programme globalement était en perl, j'ai d'abord écrit l'algo en perl.
      Premier test, durée de calcul: 15 minutes. Ah ouais.

      Alors je me démerde pour faire l'algo (seul) en C, et via un jeu de "piping" E/S, je l'appelle depuis le programme perl.
      Second test, durée de calcul: 2 secondes. Ah ouais.

      Juste pour dire que le C, quand même, c'est rapide.
  • # Re: Faille de sécurité importante dans Sendmail

    Posté par  (site web personnel) . Évalué à 4.

    Pour Slackware :

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    [slackware-security] Sendmail buffer overflow fixed

    The sendmail packages in Slackware 8.1 and -current have been patched to fix
    a security problem. All sites running sendmail should upgrade.

    More information on the problem can be found here:

    http://www.sendmail.org/8.12.8.html(...)

    Here are the details from the Slackware 8.1 ChangeLog:
    +--------------------------+
    Mon Mar 3 10:29:01 PST 2003
    patches/packages/sendmail-8.12.8-i386-1.tgz: Upgraded to sendmail-8.12.8.
    From sendmail's RELNOTES:
    SECURITY: Fix a remote buffer overflow in header parsing by dropping sender
    and recipient header comments if the comments are too long. Problem noted
    by Mark Dowd of ISS X-Force.
    (* Security fix *)
    patches/packages/sendmail-cf-8.12.8-noarch-1.tgz: Updated config files for
    sendmail-8.12.8.
    +--------------------------+



    WHERE TO FIND THE NEW PACKAGES:
    +-----------------------------+

    Updated packages for Slackware 8.1:
    ftp://ftp.slackware.com/pub/slackware/slackware-8.1/patches/packag(...)
    ftp://ftp.slackware.com/pub/slackware/slackware-8.1/patches/packag(...)

    Updated packages for Slackware -current:
    ftp://ftp.slackware.com/pub/slackware/slackware-current/slackware/(...)
    ftp://ftp.slackware.com/pub/slackware/slackware-current/slackware/(...)



    MD5 SIGNATURES:
    +-------------+

    Here are the md5sums for the packages:

    Slackware 8.1 packages:
    c2c72b982d91d9ca0f59ab2afdf337f2 sendmail-8.12.8-i386-1.tgz
    0b8e338169dca7487dd042ba070120d1 sendmail-cf-8.12.8-noarch-1.tgz

    Slackware -current packages:
    a9db559cd852164577f26efff1e9b36d sendmail-8.12.8-i386-1.tgz
    0141c1f40e1efd148f9ccd1d5a09e7f0 sendmail-cf-8.12.8-noarch-1.tgz



    INSTALLATION INSTRUCTIONS:
    +------------------------+

    As root, upgrade the sendmail package(s) with upgradepkg:

    upgradepkg sendmail-*.tgz

    Then, restart sendmail:

    /etc/rc.d/rc.sendmail restart



    +-----+

    Slackware Linux Security Team
    http://slackware.com/gpg-key(...)
    security@slackware.com
  • # Re: Faille de sécurité importante dans Sendmail

    Posté par  . Évalué à 1.

    Groumpf, j'ai vu la dépêche AFP "Internet - un bogue menace les serveurs de courrier électronique" et franchement ça la fout mal pour Internet dans son ensemble. Je crois que celui qui lit la déphêche s'en fout pas mal que ça soit Sendmail ou Blobmail++ qui est touché, tout ce qu'il retient c'est que les messages qu'il envoie peuvent être lu par de méchants hackers. Tu parles d'une publicité pour Internet...
    • [^] # Re: Faille de sécurité importante dans Sendmail

      Posté par  . Évalué à 2.

      Je te rappelle que SMTP est un protocole texte en clair donc tous les messages envoyés par ce biais peuvent être lu par de méchants hackers, faille de sécurité ou pas. Idem pour le POP. Bref, on n'est plus en sécurité nulle part mon bon Monsieur. ;-)

      PS: évidemment, il y a GPG et autres PGP
      • [^] # Re: Faille de sécurité importante dans Sendmail

        Posté par  . Évalué à 1.

        Non, c'est vrai ? Zut alors !
        ...
        C'est pas à moi qu'il faut le dire, je ne faisais que parler de la perception de l'affaire par le lecteur moyen d'un journal.
        C'est comme quand tu envoies du courrier par la poste. En principe les courriers papiers que tu envoies ne sont pas cryptés et à vrai dire ça dérange pas vraiment que quelqu'un en théorie puisse l'ouvrir pour le lire. Mais on fait à peu près confiance à la poste. Par contre si tu apprends que n'importe qui peut entrer dans les centres de tri pour fouiller dans le courrier, là tu seras pas content.
        • [^] # Re: Faille de sécurité importante dans Sendmail

          Posté par  . Évalué à 2.

          Il suffit de bien expliquer aux gens que les emails sont aussi securisés que les cartes postales envoyées sans enveloppe : tout les facteurs sur la route peuvent les lire.

          l'analogie email/courrier est AMHA moins bonne que email/carte postale.
    • [^] # Re: Faille de sécurité importante dans Sendmail

      Posté par  . Évalué à 3.

      tout ce qu'il retient c'est que les messages qu'il envoie peuvent être lu par de méchants hackers. Tu parles d'une publicité pour Internet...

      Encore cette parano ridicule... Parceque tu pense que le méchant hacker il passe son temps à lire les mails de millions de gens ? Tu pense que le méchant hacker il en a quelque chose à faire des gens qui raconte leur vie à leur(s) amis/famille ?
      Il faudrait peut être faire évoluer les mentalités des utilisateurs finaux concernant Internet, le hacking, les virus etc...

      Et quand on veut communiquer du contenu important ou confidentiel, on prend les mesures adéquoites (pop3s, PGP, serveur de mail connu et "trusté" (parceque sinon il y a toujours le méchant admin qui peut lire les mails des autres))...

      D'autant plus que les script kiddies utiliseront d'avantage un dictionnaire de mot de passe courant plus qu'un exploit difficile sur un serveur de mail...
  • # Re: Faille de sécurité importante dans Sendmail

    Posté par  (site web personnel) . Évalué à 5.

    De la part de Wichert Akkerman :

    Package : sendmail
    Problem type : remote exploit
    Debian-specific: no
    ...
    This has been fixed in upstream release 8.12.8, version 8.12.3-5 of
    the package for Debian GNU/Linux 3.0/woody and version 8.9.3-25 of the package for Debian GNU/Linux 2.2/potato.


    Merci debian.security.org.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.