Journal IMPORTANT : L'équipe Sécurité de FreeBSD vous souhaite un Joyeux Noël

Posté par . Licence CC by-sa
Tags : aucun
39
23
déc.
2011

Pour ceux qui utilisent le meilleur OS du monde, et qui l'esprit tranquille s’apprêtaient à sauter dans le train pour réveillonner en famille, l'équipe FreeBSD Security nous amène 6 jolis cadeaux :

http://lists.freebsd.org/pipermail/freebsd-security-notifications/2011-December/thread.html

1 - FreeBSD Security Advisory FreeBSD-SA-11:06.bind
Le serveur DNS dont la réputation n'est plus à faire écope d'une jolie attaque de déni de service. Cerise sur le gateau il n'y a pas besoin de forger les paquets à la main, un client DNS standard et un navigateur web classique suffisent.

2 - FreeBSD Security Advisory FreeBSD-SA-11:07.chroot
NDISPATCH se prend les pieds dans la racine. Si un utilisateur FTP du serveur FTPD arrive dans un environnement chrooté, il perd un peu les pédales et peut permettre au dit utilisateur de lancer des commandes en root.

3 - FreeBSD Security Advisory FreeBSD-SA-11:08.telnetd
Le classique qui fait toujours plaisir : telnetd ne valide pas la longueur de la clef avant de la stocker en mémoire. Donc débordement et exécution arbitraire de code avec l'utilisateur service telnetd au programme (généralement c'est root qui lance telnetd). Alors bien sur qui utilise encore telnetd ? Apparemment pas mal de monde vu que l'exploit est en train de faire un carton sur le net en ce moment. Le vieux jouet à l'ancienne qui amuse toujours autant les kiddies, c'est aussi ça l'esprit de Noël.

4 - FreeBSD Security Advisory FreeBSD-SA-11:09.pam_ssh
On reste dans les clefs du bonheur : si les clefs ssh ne sont pas stockées en mode chiffrées (unencrypted) sur le serveur, c'est la journée open bar. Le service pam-ssh ne teste pas le mot de passe si les clefs privées sont non chiffrées. On peut donc se connecter avec n'importe quel mot de passe non nul. A Noël on laisse la porte ouverte...

5 - FreeBSD Security Advisory FreeBSD-SA-11:10.pam
Pam encore, cette fois ci coté serveur. Si vous utilisez OpenPam, et un logiciel qui permet à l'utilisateur de choisir sa propre règle pam en la saisissant dans une interface, l'utilisateur peut alors très facilement rentrer un chemin complet vers le fichier de son choix, lequel sera interprété avec les droits de l'interface de choix. Donc si vous utilisez kcheckpass par exemple, un utilisateur peut très bien choisir ../../home/username/MaPolice.pam. Fou-rires garantis.

6 - Merry Christmas from the FreeBSD Security Team
La FreeBSD Security Team s'excuse pour la gène occasionnée. Pardon aux familles toussa....

Je ferais bien une news, mais là j'ai des directeurs à convaincre qu'il faut lever le "Christmas Freeze" et ensuite j'ai une grosse quinzaine de serveur à mettre à jour. Ca existe les services de livraison de dinde au marron à domicile ?

  • # J'allais faire un doublon

    Posté par (page perso) . Évalué à 10. Dernière modification le 23/12/11 à 19:24.

    J'allais faire un doublon du coup je vous livre ma prose :

    En cette veille de Fêtes alors que chacun cherche comment il va pouvoir s'esquiver rapidement demain, Colin Percival te donne une très bonne excuse pour écharper à l'orgie (Nimage).

    Pour ceux qui auraient la flemme de décrypter, il y a 5 bulletins de sécurité aujourd'hui pour FreeBSD et pas des moindres :
    - deux problèmes avec pam (notamment l'un permettant de passer root via kcheckpass)
    - un overflow des familles dans telnetd (avec un exploit root)
    - un problème complexe et intéressant mettant en oeuvre chroot et nsswitch (avec un exploit root)
    - un machin qui traînait dans bind. Car comme on dit : "tant qu'à y être autant patcher bind"

    S'il n'est pas certain que FreeBSD sauve les mamans ours, il est par contre évidant qu'il sauvera cette année certains ours des belles mamans.

  • # Quelqu'un saurait...

    Posté par . Évalué à 10.

    ... où je peux trouver du Windows Server en promo?

    Bonne fin de trolldi :)

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # Joyeux noel

    Posté par (page perso) . Évalué à 4.

    Ca existe les services de livraison de dinde au marron à domicile ?

    Bô suivant tes config ça vaut peut-être pas le coup d'y passer maintenant.

    1 - FreeBSD Security Advisory FreeBSD-SA-11:06.bind

    c'est sûr que c'est ballot mais à moins d'avoir des resolvers publiques le risque est quand même mince. Puis bon si on arrête de vivre à chaque vulnerabilité de bind ...

    2 - FreeBSD Security Advisory FreeBSD-SA-11:07.chroot

    Il ne marche qu'avec ftpd + /etc/ftpchroot ou proftpd. Pour info pureftpd n'est pas affecté. Ni openssh en mode sftp chrooté

    3 - FreeBSD Security Advisory FreeBSD-SA-11:08.telnetd

    telnetd c'est mal

    4 - FreeBSD Security Advisory FreeBSD-SA-11:09.pam_ssh

    tu utilises pam_ssh ?

    5 - FreeBSD Security Advisory FreeBSD-SA-11:10.pam

    Je n'ai pas trouvé d'autres exemples que kcheckpass qui est setuid. sudo est exempt. Donc point de kde ...

    Pour moi le problème du ftp ayant déjà été traité depuis l'annonce sur full disclosure, le reste attendra quelques jours sans problèmes.

    • [^] # Re: Joyeux noel

      Posté par (page perso) . Évalué à 7.

      c'est sûr que c'est ballot mais à moins d'avoir des resolvers publiques

      Tout mes serveurs Bind le sont.

      • [^] # Re: Joyeux noel

        Posté par (page perso) . Évalué à 4.

        Tout mes serveurs Bind le sont.

        Dans ce cas, joyeux noël :(

        • [^] # Re: Joyeux noel

          Posté par . Évalué à 10.

          D'façon, les gens qui utilisent BSD vivent dans une conception du temps différente de la notre. Ils n'ont pas de vie, pas de relation sociales. Ils ne voient pas leur famille, sauf pour dépanner leurs ordinateurs. Noël n'est qu'un timestamp qui n'a rien de particulier pour eux.

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: Joyeux noel

            Posté par . Évalué à 10.

            correction :
            les gens qui vivent BSD utilisent une conception du temps différente de la nôtre.

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

          • [^] # Re: Joyeux noel

            Posté par . Évalué à 2.

            Tu veux dire que FreeBSD va tellement vite par rapport à Linux, que des effets relativistes se font ressentir ? Dilatation du temps du à une vitesse proche de la lumière ?

            • [^] # Re: Joyeux noel

              Posté par . Évalué à 3.

              si les admins ne font rien ce n'est pas le temps qui va se dilater

      • [^] # Re: Joyeux noel

        Posté par . Évalué à 1.

        Mauvaise idée.
        D'une part, tu participes potentiellement aux jolies attaques par amplification.
        D'autre part, c'est une erreur de conception d'avoir mis dns auth et le resolver dans le même logiciel. Ça peut avoir de facheuses concéquences. Typiquement quand tu as la zone en local et que ça tombe en marche alors que la zone n'est pas déléguée.

        • [^] # Re: Joyeux noel

          Posté par . Évalué à 3.

          Typiquement quand tu as la zone en local et que ça tombe en marche alors que la zone n'est pas déléguée.

          J'ai pas tout compris la.
          Tu as une zone qui tombe et pas de "slave". Bon la zone est plus joignable.

          Je vois pas ce que vas changer le fait d'avoir un resolveur.

          • [^] # Re: Joyeux noel

            Posté par . Évalué à 4.

            La résolution et l'hébergement de zones sont deux boulots différents. Ça n'est pas parce qu'un même logiciel permet de faire les deux qu'il faut le faire. Un peu comme squid, il sait à la fois faire proxy pour des clients et reverse, mais bizarrement personne ne pense à faire les deux sur la même machine.

            Parmis les problèmes que ça pose:
            - La plupart des failles bind sont liés au resolver. Activer le resolver sur des dns auth augmente donc énormement les risque de voir son NS en panne.
            - Problèmes d'incohérences dans la résolution si des zones sont définies en local.

            • [^] # Re: Joyeux noel

              Posté par . Évalué à 2.

              • La plupart des failles bind sont liés au resolver. Activer le resolver sur des dns auth augmente donc énormement les risque de voir son NS en panne. Il s'agit juste de la portée d'attaque.

              En cas de résolveur publique je suis 100% d'accord (mais qui actuellement s'amuser à mettre des récursif en publique, autre que les ISP)

              En cas de résolveur privée, bien que 80% des attaques proviennent de l'intérieur, tu controles ton réseau et les utilisateurs.
              Je reste totalement dubitatif.

              En cas de resolveur dédié uniquement à une infra (donc que des serveurs que du controle), je suis 100% pas d'accord (de toute façon si le resolveur tombe, tu auras un sacré problème, et le fait que ton authoritaire pointé par ton resolveur marche, tu t'en fous complètement).

              • Problèmes d'incohérences dans la résolution si des zones sont définies en local.

              Il n'y a aucune incohérence, les zones définies en locale seront celles utilisées.
              A toi (l'admin de la zone ou de la surcharge) de savoir ce qu'il fait.

              C'est d'ailleurs très utile lorsque tu veux changer des records dans des zones externes .

              Si ensuite tu t'amuse a mixer des serveurs configuré complètement différement là on y peut rien, tu auras un moment ou un autre un problème de cohérence.

              bref, ce n'est pas parce qu'on peut faire des sysèmes vachement complexe qu'il faut tout le temps les faire.
              Des fois le KISS maarche tout aussi bien, voir bien mieux (et surtout en cas de problème).

  • # DragonFlyBSD

    Posté par (page perso) . Évalué à 5.

    Si vos utilisez telnetd sous DragonFlyBSD pensez à faire une mise à jour également.

    http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/e2decfa00070772e0f0eb2531bad6efdb84a403b

  • # Le choix dans la date

    Posté par (page perso) . Évalué à 10.

    Au cas où il y en ait qui pensent que le projet FreeBSD est une entité diabolique, qui ne fait rien que saboter les fêtes chrétiennes et empêcher les admins sys d'aller à la messe de minuit, voici un message de l'équipe de sécurité :

    Hi all,

    No, the Grinch didn't steal the FreeBSD security officer GPG key, and your eyes aren't deceiving you: We really did just send out 5 security advisories.

    The timing, to put it bluntly, sucks. We normally aim to release advisories on Wednesdays in order to maximize the number of system administrators who will be at work already; and we try very hard to avoid issuing advisories any time close to holidays for the same reason. The start of the Christmas weekend -- in some parts of the world it's already Saturday -- is absolutely not when we want to be releasing security advisories.

    Unfortunately my hand was forced: One of the issues (FreeBSD-SA-11:08.telnetd) is a remote root vulnerability which is being actively exploited in the wild; bugs really don't come any worse than this. On the positive side, most people have moved past telnet and on to SSH by now; but this is still not an issue we could postpone until a more convenient time.

    While I'm writing, a note to freebsd-update users: FreeBSD-SA-11:07.chroot has a rather messy fix involving adding a new interface to libc; this has the awkward side effect of causing the sizes of some "symbols" (aka. functions) in libc to change, resulting in cascading changes into many binaries. The long list of updated files is irritating, but isn't a sign that anything in freebsd-update went wrong.

    (flemme de traduire...)

  • # Et je viens de dégager Debian ...

    Posté par . Évalué à -1.

    Tout cela est cocasse.

    Sur reconstruction de serveur@home il y a à peine 1 semaine, mon choix s'est orienté sur cet OS (un brin de folie ne faisant jamais de mal), d'ailleurs j'apprécie vraiment je ne regrette pas la transition c'est vraiment de l'horlogerie suisse, et c'est vraiment light !

    Ca fait vraiment plaisir de faire un "top" et d'avoir quelque chose de clair, et ne ne pas voir un ramassis de process noyo kdmachintruc (alors que tu n'as installé que base et que tu te demandes, la première fois, ce que vient foutre un process KDE là ..) et j'en oublie, squatter la file de ton ordonnancement même si ils font dodos.
    Bon pour dédramatiser, proposition de correction pérenne sur telnetd/telnet > bannir ce paquet des ports (en tout cas pour les ix86 et archi serveur). A moins de contraintes ultra fortes sur du matos embarqué/réseau, hors utilisation humaine, je ne vois pas encore l'utilité d'utiliser un tel accessoire. (Qu'on me démontre que je me trompe.)

    Je suis plus inquiet pour la faille chroot FTPD là par contre, disons qu'elle est vraiment grossière, qu'elle fait tout de même peu sérieuse. Et peu sérieux de ne pas utiliser une transaction un peu plus sécurisée également (malheureusement des FTP tout secs on en croise "en veux-tu en voilà" partout même dans le contexte pro).
    Enfin, ce qui est inquiétant, il s'agit simplement d'une possibilité de fonctionnement basique non testée, et c'est encore plus vrai pour pam-ssh.

    Ce qu'on peut déduire de tout ça : FreeBSD manque cruellement de testeur.

Suivre le flux des commentaires

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