Journal Faille de sécurité glibc

Posté par . Licence CC by-sa
38
27
jan.
2015

Je me permets de faire un copier coller de l'annonce relayée sur le FRench SysAdmins Group (FRsAG):

**
/Cette vulnérabilité sévère détectée dans la bibliothèque C de GNU/Linux donne le contrôle aux attaquants sans nécessiter d’identifiants système.
- Patchs disponibles dès aujourd’hui - /

*
Le 27 janvier 2015 –– *Qualys, Inc.(NASDAQ : QLYS), le principal fournisseur de solutions de sécurité et de conformité dans le Cloud, annonce que son équipe chargée de la recherche en sécurité a découvert dans la bibliothèque C de GNU/Linux (glibc) une vulnérabilité critique qui permet aux pirates de prendre le contrôle à distance de tout un système, en se passant totalement des identifiants système.
Qualys a travaillé de manière étroite et coordonnée avec les fournisseurs de distributions Linux pour proposer un patch pour toutes les distributions de systèmes Linux touchés.
Ce patch est disponible dès aujourd’hui auprès des fournisseurs correspondants.

Baptisée GHOST (CVE-2015-0235) parce qu’elle peut être déclenchée par les fonctions gethostbyname et gethostbyaddr, cette vulnérabilité touche de nombreux systèmes sous Linux à partir de la version glibc-2.2 publiée le 10 novembre 2000. Les chercheurs de Qualys ont par ailleurs détecté plusieurs facteurs qui atténuent l’impact de cette vulnérabilité, parmi lesquels un correctif publié le 21 mai 2013 entre les versions glibc-2.17 et glibc-2.18.
Malheureusement, ce correctif n’ayant pas été classé comme bulletin de sécurité, la plupart des distributions stables et bénéficiant d’un support à long terme ont été exposées, dont Debian 7 (« Wheezy »), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7 et Ubuntu 12.04.

Les clients Qualys peuvent détecter GHOST à l’aide de la signature QID 123191 fournie par le service Cloud Qualys Vulnerability Management(VM). Lorsqu’ils lanceront le prochain cycle de scan, ils obtiendront des rapports détaillés sur l’exposition de leur entreprise à cette vulnérabilité sévère. Ils pourront ainsi estimer son impact sur leur activité et suivre efficacement la vitesse de résolution du problème.

« GHOST expose à un risque d’exécution de code à distance qui rend l’exploitation d’une machine par un pirate terriblement enfantine.Il suffit par exemple qu’un pirate envoie un mail sur un système sous Linux pour obtenir automatiquement un accès complet à cette machine »,
explique Wolfgang Kandek, Directeur technique de Qualys, Inc. « Compte tenu du nombre de systèmes basés sur glibc, nous considérons qu’il s’agit d’une vulnérabilité sévère qui doit être corrigée immédiatement.La meilleure marche à suivre pour atténuer le risque est d’appliquer un patch fourni par votre fournisseur de distributions Linux. »

Les correctifs sont disponibles pour Debian wheezy.

  • # Prems LOL

    Posté par . Évalué à -10. Dernière modification le 27/01/15 à 17:12.

    encore une belle prouesse du logiciel libre cette révélation
    un beau signal envoyé aux décideurs

    • [^] # Re: Prems LOL

      Posté par . Évalué à -10.

      les décideurs ont décidés qu'ils devaient faire des économies coûte que coûte, et ça passe, selon eux, par l'abandon des Unix proprios au profit du couple linux/x86.

      Ce n'est pas les failles de sécurité qui vont arrêter cette fuite en avant, d'autant que le patch management des OS/socles techniques est un processus maintenant mûrs dans les esprits de maitrises d'oeuvre.

    • [^] # Re: Prems LOL

      Posté par (page perso) . Évalué à 10. Dernière modification le 27/01/15 à 17:39.

      un beau signal envoyé aux décideurs

      Oui, très beau : il donne confiance aux décideurs en montrant la capacité de réaction de l'environnement Linux, au contraire des tentatives de cacher des autres fournisseurs (tien, le dernier en date de Google qui a attendu 90 jours mais Microsoft n'était pas motivé pour se bouger les fesses et du coup il a fallu puplier pour que Microsoft se bouge plus vite, et il y en a tellement des failles remontées mais dont l'upstream se fout, quand c'est pas en libre).
      Le libre est super de ce côté, tout le monde peut voir ce qu'il se passe, rien n'est caché, on voit aussi le temps de réaction et ça aide à avoir confiance.

      Du coup je ne comprend pas le ton "ironique" du commentaire (où je vois le mal partout en imaginant que des gens pensent que les autres fournisseur n'ont jamais de bugs?)

      • [^] # Re: Prems LOL

        Posté par . Évalué à -8.

        les décideurs s'en fichent, en général, de la réactivité de la communauté.

        Car s'ils s'intéressaient vraiment à la communauté, ils n'achèteraient pas des distributions commerciales avec un support classique comme avec les autres fournissieurs…ils feraient confiance et s'appuieraient davantage sur leur employés.

        Je dis ça pour le cadre général, je ne dis pas que tous les décideurs sont comme ça hein.

        • [^] # Re: Prems LOL

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

          Redhat fait partie de la communauté (et pas qu'un peu).
          Quand aux employés, tout le monde n'a pas le fric pour embaucher un expert sécurité Linux et s'appuie alors sur un support. Normal. Le commercial n'est pas le mal contrairement à ce que tu sous-entend, et offre quelque chose que d'autres (que tu semble plus aimer) n'offre pas.

          Et justement, les décideurs voient que pour moins que HPUX et SunOS, on peut avoir de la sécurité.

          • [^] # Re: Prems LOL

            Posté par . Évalué à 1.

            ce que je sous entend, c'est que le choix d'avoir une distrib commerciale avec un support classique, c'est d'avoir quelqu'un sur qui taper en cas de problème au niveau des responsabilités, c'est donc le même modèle qu'avec les unix proprios ou logiciel proprio d'une manière générale.

            Donc le choix de linux dans pas mal d'entreprises, ce n'est pas pour choisir du liber, c'est surtout pour faire des économies et suivre la mode, et parfois pour suivre l'innovation. Les banques et assurances en sont les exemples les plus criants et je parle d'expérience.

            Le commercial n'est pas le mal, d'ailleurs RMS dit souvent "Libre is not gratuit".

            • [^] # Re: Prems LOL

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

              le choix d'avoir une distrib commerciale avec un support classique, c'est d'avoir quelqu'un sur qui taper en cas de problème au niveau des responsabilités

              Même si dans les faits c'est sans doute souvent vrai, dans l'absolu c'est tout-à-fait faux. Avec ta distrib' purement communautaire, si tu tombes sur un bug critique pour toi mais pendant les vacances au Tibet du mainteneur du paquet fautif, bah t'attends 15 jours qu'il ait finit de crapahuter chez les bouquetins et tu mets éventuellement la clé sous la porte. Ou alors comme dit Zenitram t'embauches tous les meilleurs spécialistes du monde… pour avoir quelqu'un sur qui taper, en fait ?

              • [^] # Re: Prems LOL

                Posté par . Évalué à 3.

                C'était peut-être vrai dans les années 1990 et début 2000. Aujourd'hui la maintenance de paquets se fait beaucoup en équipe (en tout cas pour Debian c'est le cas) via des CVS comme git. Les bugs critiques sur des paquets critiques sont traités extrêmement rapidement. Il y a même des équipes sécurité qui sont dévouées à ce travail.
                Après oui certains paquets utilisés par peu de personnes et non critiques peuvent attendre longtemps et encore il est possible d'avoir des mises à jour du paquet par d'autres mainteneurs. Je pense par exemple aux NMU (non maintainer upload) chez Debian.

            • [^] # Re: Prems LOL

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

              Je connais une banque française ( dont je vais taire le nom, principalement parce que j'ai oublié ou la personne qui m'a dit ça lors d'un meetup travaille ) qui a des gens qui teste TheForeman et qui sont en avance de phase, pour reprendre leur termes vis à vis de certains produits RH, justement en vue de faire des retours plus tôt. Le fait d'avoir du logiciel libre permet pour eux ce genre de liberté, aussi bien en test plus rapide que de participer à la boucle de retroaction au coeur de l'innovation du logiciel libre.

              • [^] # Re: Prems LOL

                Posté par . Évalué à 10.

                Tu veux dire qu'ils leveragent des synergies structurantes pour des partenariats win-win ?

                • [^] # Re: Prems LOL

                  Posté par . Évalué à 9.

                  FOUTAISES !!!

                  • [^] # Re: Prems LOL

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

                    Je vois qu'il y a ici de plus en plus de petits Djeunz qui ne connaissent pas encore le Business Loto.
                    Tout se perd ma pôv' dame. :-(

            • [^] # Re: Prems LOL

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

              le choix d'avoir une distrib commerciale avec un support classique, c'est d'avoir quelqu'un sur qui taper en cas de problème au niveau des responsabilités, c'est donc le même modèle qu'avec les unix proprios ou logiciel proprio d'une manière générale.

              Parce que chez RedHat, quand tu es client, c'est du support classique ? Ou juste tu es en prise directe avec des gens qui fabriquent Linux ?

              * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

              • [^] # Re: Prems LOL

                Posté par . Évalué à 2.

                Par expérience, c'est du support classique, typique des contrats de support de logiciel propriétaire au niveau réactivité et qualité des réponses.

                • [^] # Re: Prems LOL

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

                  Salut,
                  Dans mon expérience c'est un support de très bonne qualité globale.
                  Les 1ers niveaux racontent très rarement des conneries. Si nécessaire, tu peux remonter très rapidement vers les développeurs noyau concernés. Avec donc noyaux de tests/debug patchés et inclusion mainstream rapide.
                  Après, je ne sais pas quel support on paye, mais sans doute beaucoup.

                  • [^] # Re: Prems LOL

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

                    On n'a vraiment pas la même expérience du support RedHat :)

                    • [^] # Re: Prems LOL

                      Posté par . Évalué à 3.

                      Le support Redhat est vraiment très bien. On peut aller boire un coup avec lui, voire même être hébergé chez lui quelque jours.

                      En fait je confonds peut-être le support et les gens qui le composent. /o\

                      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                    • [^] # Re: Prems LOL

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

                      Bah après si t'as une licence desktop à 60 boules par an, ils vont pas forcément sortir Con Kolivas du formol dès que t'as un souci.

      • [^] # Re: Prems LOL

        Posté par . Évalué à -10.

        Pincer moi, Zenitram qui defend le libre et linux…

        • [^] # Re: Prems LOL

          Posté par (page perso) . Évalué à 10. Dernière modification le 27/01/15 à 17:59.

          Quand les gens comprendront que d'autres peuvent être neutres sur des OS, et savoir faire autre chose que d'être fanatique d'un OS au point de mettre des oeillères sur ses défauts… Comme les autres OS, Linux a plein de défauts, et… d'avantages.
          Ici, il y a généralement assez de personnes pour défendre Linux pour que je n'ai pas besoin de le faire, tu me vois juste parler des défauts de Linux faute de personnes le faisant ici (et sur un site pro-Windows, on dirait "Pincer moi, Zenitram qui defend Windows…", et sur un site pro-Mac on dirait "Pincer moi, Zenitram qui defend Mac…", rien de nouveau, des gens ont décidé que si on n'est pas 100% avec eux, on est forcément contre eux)

          Voir que maintenant que je peux parler des avantages de Linux est démonstratif d'un énorme volonté de se cacher les posts précédents.

          Voila, ça te permettra d'avoir un bouton "moinsser" et te refaire plaisir.

          • [^] # Re: Prems LOL

            Posté par . Évalué à 10.

            Ici, il y a généralement assez de personnes pour défendre Linux pour que je n'ai pas besoin de le faire, tu me vois juste parler des défauts de Linux faute de personnes le faisant ici (et sur un site pro-Windows, on dirait "Pincer moi, Zenitram qui defend Windows…", et sur un site pro-Mac on dirait "Pincer moi, Zenitram qui defend Mac…", rien de nouveau, des gens ont décidé que si on n'est pas 100% avec eux, on est forcément contre eux)

            Donc en fait t'es un gros troll. :-)

            Parce qu'en fait si les gens ont un problème avec tes critiques, ce n'est pas parce que tu ne donnes pas d'arguments (très souvent tu le fais, même si on n'est pas forcément d'accord), mais bien parce que tu ne peux pas t'empêcher, après une argumentation parfois béton, de dire « c'est marrant ces {linuxiens|libristes|windowsiens|mac-eux|footeux|.*}1 qui pensent que […] », avec une certaine suffisance, voire une certaine condescendance. Je pense que la brutalité des propos, ou le fait d'être critique en soi n'est pas mal vu ici. C'est le côté extrême de l'argumentation, façon « tout ou rien », ce qui inclue certaines généralisations que tu fais, qui rebute les gens.


            1. En fonction du site où tu officies a priori, donc. :-) 

          • [^] # Re: Prems LOL

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

            des gens ont décidé que si on n'est pas 100% avec eux, on est forcément contre eux

            Un peu comme toi lorsque quelqu'un a un avis qui diverge légèrement du tiens, et que tu le transformes en un avis complètement opposé au tiens.

            Opera le fait depuis 10 ans.

      • [^] # Re: Prems LOL

        Posté par (page perso) . Évalué à -2.

        Le libre est super de ce côté, tout le monde peut voir ce qu'il se passe, rien n'est caché, on voit aussi le temps de réaction et ça aide à avoir confiance.

        Oué grâce au libre tout le monde pouvait effectivement voir qu'il y avait un bug présent depuis plus de 10 ans dans le code, tout le monde a également pu voir que ce bug a été identifié publiquement en 2013 et qu'il a fallut atteindre 2015 pour qu'une société l'identifie comme dangereux.

        Ca donne effectivement confiance, on se dit qu'il n'y a sans doute aucune personne malintentionné qui est pu exploiter cette vulnérabilité avant.

        • [^] # Re: Prems LOL

          Posté par . Évalué à 7.

          http://securityintelligence.com/ibm-x-force-researcher-finds-significant-vulnerability-in-microsoft-windows/#.VGUPzvnF-Sp

          Certes la le trou il datait pas de 10 ans mais carrement de 19 ans.

          Donc le fait qu'un bug soit present dans un code pendant des annees avant d'etre decouvert n'a absolument rien avoir avec le fait que le code soit libre ou pas. Il faut que le code soit relu (eventuellement) et de plus parfois des choses qui pouvaient etre legitimes a un temps peuvent se revele une cata quelques temps plus tard.

          • [^] # Re: Prems LOL

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

            Donc le fait qu'un bug soit present dans un code pendant des annees avant d'etre decouvert n'a absolument rien avoir avec le fait que le code soit libre ou pas. Il faut que le code soit relu (eventuellement)

            Ouais enfin c'est quand même plus facile d'auditer du code libre que du code proprio closed-source hein :)

            Le pire reste quand même le fait que le bug ait été découvert en 2013 et identifié comme dangereux qu'en 2015 : j'imagine que ceux qui cherchent des failles de sécu se régalent des mailing-lists de "patch" anodins et regardent les bugs corrigés avec un œil totalement différent du développeur lambda qui n'a vu qu'un simple "bug".

            • [^] # Re: Prems LOL

              Posté par . Évalué à 1.

              Enfin malgre tout cette faille n'est pas officiellement exploite, a ete corrige et maintenant toutes les distribs sont a jour. Donc c'est super de dire que parceque le code est libre il est moins secure car plus facile a auditer mais cela n'est que du FUD.

              • [^] # Re: Prems LOL

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

                Je dis pas que le libre est moins secure, je relativise la "confiance" liée à la "forte réactivité" de la communauté.

                Mais bon comme tu le dis si bien je dois avoir tord puisque la faille n'a pas été "officiellement" exploitée. Me voilà rassuré et confiant.

            • [^] # Re: Prems LOL

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

              Bug découvert en 2013 et identifié comme dangereux en 2015 : c'est sur, ça ne serait jamais arrivé chez un éditeur proprio (ou pas).

  • # Quick fix

    Posté par . Évalué à 10.

    Il suffit de supprimer la libc:-)

  • # Pas 'dredi

    Posté par . Évalué à -10.

    On a des listes de diffusion pour les problèmes de sécurité, on va pas se mettre à reposter tous les CVE ici.

    • [^] # Re: Pas 'dredi

      Posté par . Évalué à 10.

      Tout le monde ne suit pas les listes de diffusion pour les problèmes de sécurité.

      Et ici, il ne s'agit pas de n'importe quel CVE. Compte tenu de la sévérité de la faille et de l'impact sur l'ensemble des distributions GNU/Linux (le GNU a son importance ici), ce journal ne me semble pas inutile.

  • # trop tôt

    Posté par (page perso) . Évalué à 4. Dernière modification le 27/01/15 à 17:48.

    http://www.frsag.org/pipermail/frsag/2015-January/005727.html
    oups :)

    Bon ça arrive : https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235

    Reste que ce qui a été transmis dnas le journal est plus de la publicité qu'une annonce de faille, on peut peut-être virer la partie pub?

    • [^] # Re: trop tôt

      Posté par . Évalué à 6.

      Ah ouai donc maintenant des boîtes de sécu embauchent des boîtes de communication pour annoncer les failles ? Tu m'étonnes du fail…

      • [^] # Re: trop tôt

        Posté par . Évalué à 10.

        Il manque encore le logo de la faille par contre. Une annonce d'une nouvelle faile sans un logo, ca fait pas très serieux quand meme.

        • [^] # Re: trop tôt

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

          Le voilà :)
          Titre de l'image

          • [^] # Re: trop tôt

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

            OMFG, mais ce n'est pas un prompt Unix classique !

            * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

            • [^] # Re: trop tôt

              Posté par . Évalué à 3.

              Non, c'est un shoot'em up à scrolling horizontal.

            • [^] # Re: trop tôt

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

              Et c'est du JPEG… Pour quelqu'un qui fait des logos, évoquer un contexte différent de ce dont on parle (un prompt DOS pour une faille GNU) et en plus utiliser un format d'image inadapté, ça cumule…

            • [^] # Re: trop tôt

              Posté par . Évalué à 4.

              export PS1=">_ "

              'service

      • [^] # Re: trop tôt

        Posté par . Évalué à 3.

        Veronique Loquet est plus journaliste que PR je dirais, elle est assez impliquée dans le milieu sécurité et s'occupe notamment d'organiser (avec d'autres) NoSuchCon en France.

  • # Sans le bullshit marketing

    Posté par . Évalué à 1.

    Cette annonce ne sert strictement à rien techniquement parlant et fait sa promo de manière tellement éhontée…

    Voir https://sourceware.org/bugzilla/show_bug.cgi?id=15014 pour une exploitation du bug, et https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235 pour le patch.

    En résumé, avec une taille insuffisante du buffer passé à gethostbyname_r(), pour faire des résolutions inverse de nom, on peut éventuellement exécuter du code. Mouai. C'est un buffer dont la taille et l'allocation n'est pas contrôlée par l'utilisateur, seul l'IP à résoudre le sera éventuellement. Bref, c'est assez mince comme faille.

    • [^] # Re: Sans le bullshit marketing

      Posté par (page perso) . Évalué à 6. Dernière modification le 27/01/15 à 17:53.

      Il semble que tes liens parlent d'un truc de 2013, jugé pas important (pas de CVE), et aujourd'hui c'est monté en faille de sécurité (ticket ouvert en 2013, CVE assigné en 2015)
      J'imagine qu'un gus a trouvé comment exploiter la faille de manière plus dangereuse, et tu n'explique pas en quoi le changement de statut en 2015 est mince.

    • [^] # Re: Sans le bullshit marketing

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

      Bref, c'est assez mince comme faille.

      Ouf ça me rassure parce que quand j'ai lu http://www.openwall.com/lists/oss-security/2015/01/27/9 ("As a proof of concept, we developed a full-fledged remote exploit against the Exim mail server, bypassing all existing protections (ASLR, PIE, and NX) on both 32-bit and 64-bit machines"), j'ai eu un peu peur et j'ai cru que j'allais devoir mettre à jour toutes mes Debian Lenny

      • [^] # Re: Sans le bullshit marketing

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

        Voici un commentaire de Spender qui dit lui aussi que ce n'est pas aussi critique qu'annoncé et que Qualys a choisi de gonfler l'importance du truc pour se faire mousser :

        https://lwn.net/Articles/630854/

        • [^] # Re: Sans le bullshit marketing

          Posté par . Évalué à 10.

          Ce bug n'est pas la fin du monde comme annoncé. On peut rire et se moquer du PR de Qualys, mais je pense qu'il faut saluer le boulot qu'ils ont fait.

          Le rapport est fouillé, travaillé, ils donnent le code d'exploit et l'analyse du code source. Ils ont passé en revue un grand nombre de binaires système et indiquent dans quels cas ceux-ci peuvent être vulnérable ou non.

          Mais surtout, alors que personne n'avait rien trouvé comme vecteur d'exploitation distant (ni le bug initial, ni sa redécouverte chez google), ils ont eu l'idée d'utiliser un header SMTP et ont trouvé un serveur vulnérable. L'exploit derrière est propre (ils indiquent comment contourner ASLR, NX etc..). Donc chapeau bas pour la qualité technique de l'article de Qualys, c'est pas un de cas vagues bug report qui dit: "une erreur non spécifiée peut provoquer un overflow et éventuellement exécuter du code, OMG OMG OMG!!!".

    • [^] # Re: Sans le bullshit marketing

      Posté par . Évalué à 10.

      Voila une analyse technique de GHOST qui t'intéressera je pense : http://lcamtuf.blogspot.com/2015/01/technical-analysis-of-qualys-ghost.html?m=1

      :)

  • # En parlant de faille concernant une bibliothèque partagée...

    Posté par . Évalué à 10.

    Lorsqu'il s'agit d'une bibliothèque dont l'utilisation est limitée à un service, je me dis qu'il suffit de redémarrer le service en question après avoir appliqué les mises à jour.

    Mais avec une bibliothèque aussi centrale que la glibc, un redémarrage de la machine est-il indispensable ou bien un redémarrage de tous les services après la mise à jour suffit-il pour protéger une machine ?

    • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

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

      La glibc, comme le noyau (du moins pour une partie) et d'autres composants d'aussi bas niveau dans le système requiert un redémarrage pour être certain que cela a bien été corrigé dans tout le système.

      Car la libc c'est chargé en mémoire assez rapidement au démarrage et il est peu probable qu'il soit déchargé autrement que par l'extinction de la machine (sinon tout le système s'effondre).

      • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

        Posté par . Évalué à 2.

        j'ai même envie de dire qu'un reboot est obligatoire car le moindre petit programme de rien du tout fait appel à la libc, ce qui fait que celle-ci reste chargée en mémoire (shared lib) tant qu'on l'utilise.

        Les symboles exportés restent donc ceux de l'ancienne shared lib.

        D'ailleurs, avec quelle commande sait-on sous Linux pour afficher les programmes utilisant un shared lib ?

        Sur un os de professionnel comme AIX ça se fait avec la commande "genld -l".
        Ca donne ce genre de sortie :

        Proc_pid: 3932522 Proc_name: ksh93
        100000000 1a7b86 ksh93
        9fffffff0000000 fa8e /usr/ccs/bin/usla64
        90000000046f980 e9bd /usr/lib/libi18n.a[shr_64.o]
        90000000cc0c000 6558c5 /usr/lib/nls/loc/EN_US.UTF-8__64
        900000000461400 b43 /usr/lib/libcrypt.a[shr_64.o]
        90000000047f780 3013b /usr/lib/libiconv.a[shr4_64.o]
        900000000000000 43b3bf /usr/lib/libc.a[shr_64.o]

        Quand on met à jour une shared lib moins cruciale que la libc, on peut vérifier assez rapidement que plus personne ne l'utilise.

        Une fois cette vérification effectuée, on utilise la commande "slibclean" pour forcer le déchargement de la shared lib. On peut ensuite relancer les programme nécessitant la shared lib mise à jour, on est enfin sûr que tous les programmes se servent de la nouvelle version.

        comment faire de même avec Linux ? J'ai cru comprendre qu'il fallait forcer le commit du cache fichier avec un :

        $ echo 3 > /proc/sys/vm/drop_caches

        Mais en résumé, c'est toujours frustrant de devoir rebooter un Unix à cause d'un composant de haut niveau….

        • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

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

          Pour ma part j'utilise needrestart, qui repère une grande partie des démons à relancer.
          Je ne sais pas comment c'est géré niveau système derrière, mais en tous cas après redémarrage les démons en question ne sont plus identifiés par needrestart comme exploitant une vieille version de la libc.

          alf.life

          • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

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

            checkrestart (sur lequel se base needrestart), se base sur les bibliothèques partagées utilisés par les processus en cours d'exécution et qui ont été supprimées du système de fichier.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

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

      "Dans le doute, reboot!"

    • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

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

      Après une mise à jour sans reboot sur Debian Wheezy, j'ai compilé GHOST.c fourni ici puis lancé l'exécutable :

      $ ./GHOST
      not vulnerable
      

      Ça ne prouve pas qu'il ne faut pas rebooter (peut-être que d'autres trucs déjà lancés restent vulnérables), mais le résultat inverse aurait prouvé que le reboot était nécessaire.

      blog.rom1v.com

      • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

        Posté par . Évalué à 4.

        Il faut soit redemarrer tous les processus qui tournent en utilisant l'ancienne libc, soit rebooter.

        • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

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

          un bon vieux checkrestart (outil disponible dans le paquet debian-goodies) te permet de savoir s'il existe des programmes et des services résidents en mémoire qui utilisent les anciennes versions des bibliothèques mises à jour.

          Grâce à ca, mon serveur en debian Wheezy a un uptime de plus de 2 ans maintenant !
          (j'ai toujours adoré jouer le jeu de l'uptime tout seul /o\ )

          • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

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

            Cool je savais pas que Debian avait implémenté un /etc/init.d/kernel restart sans redémarrage.

            • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

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

              c'est à dire que le kernel n'utilise pas la glibc, c'est plutôt l'inverse, si j'ai bien tout compris…

              • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

                Posté par . Évalué à 10.

                Le kernel a régulierement des updates de sécurité lui aussi. Il n'y a pas que la glibc.

                • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

                  Posté par . Évalué à 4.

                  C’est quand la dernière faille exploitable à distance dans le kernel ? La plupart des failles du kernel, c’est un utilisateur local qui peut faire un DoS. Et dans le reste des failles, la majorité c’est « en branchant un périphérique soigneusement fabriqué à cet effet, on peut faire xxx » (honnêtement si le serveur est dans un datacenter OSEF…). Les élévations de privilège, les exécutions de code en espace noyau, et les exécutions de code à distance sont extrêmement rares.

                  • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

                    Posté par (page perso) . Évalué à 5. Dernière modification le 28/01/15 à 09:44.

                    Les élévations de privilège (…) sont extrêmement rares.

                    Bon, au pif, mais il y en a plein d'autres.
                    Babelouest indique surtout que si on arrive à choper un pass (ou clé) d'un compte "local" (entre guillement car local n'a pas grand sens quand on se connecte en SSH) quelconque de sa machine, on peut devenir root (pas besoin du pass root vu que son noyau a 2 ans), bref que tout utilisateur de sa machine est root.

                    On va dire que c'est chacun sa vision de la sécurité sur une machine dont il est plus important d'afficher un gros uptime (et/ou que certaines personnes croient qu'ils sont naturellement imunisés contre le vol de pass/clé)

                    • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

                      Posté par . Évalué à -4.

                      T'as pas plus recent?

                      Car bon noyau 3.14 et "This issue does not affect the versions of Linux kernel as shipped with Red Hat Enterprise Linux 5, 6, 7 and Red Hat Enterprise MRG 2."

                      Sans compter :

                      Access vector: "Local"

                      Donc tu dois trouver un autre exemple ca mnarche pas celui la car tu repondais a la question : C’est quand la dernière faille exploitable à distance dans le kernel ?

                      • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

                        Posté par . Évalué à -10.

                        Les cretins qui moinssent le message qui corrige les conneries de Zenitram peuvent t'ils avoir le courage d'expliquer cela?

                        Cela ne vous plait pas la verite?

                        • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

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

                          Faut vraiment répondre?

                          Bon vite fait :

                          T'as pas plus recent?

                          Euh… Tu as lu?

                          Red Hat Enterprise Linux 5, 6, 7

                          Ben oui, RHEL 7 c'est du 3.10, et j'ai parlé de 3.14. J'ai trop récent!
                          Du coup, c'est pour les "beta" de RHEL, soit Fedora. si tu avais lu, tu saurais.

                          Donc tu dois trouver un autre exemple ca mnarche pas celui la car tu repondais a la question : C’est quand la dernière faille exploitable à distance dans le kernel ?

                          Et j'ai répondu à "Les élévations de privilège" que j'ai cité. Sans compter que j'ai parlé de la notion de "local", en expliquant que le local était chopable… à distance.

                          Les cretins

                          Ou alors, les gens moinssent car tu n'as pas lu à ce à quoi tu réponds, tu as lu partiellement le lien, tu mélange pas récent et trop récent…

                          Mais j'ai sans doute été crétin de répondre à une personne qui ne va pas essayer de comprendre pourquoi elle a été moinssée, mais si elle attaque une personne que pas mal de monde aime attaquer d'habitude, et ne pas essayer de relire et comprendre pourquoi elle a été moinssée : c'est tellement plus simple d'insulter! On m'a toujours dit que l'insulte était la démonstration du manque de confiance dans les arguments.

                          • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

                            Posté par . Évalué à 1.

                            Mais j'ai sans doute été crétin de répondre à une personne qui ne va pas essayer de comprendre pourquoi elle a été moinssée, mais si elle attaque une personne que pas mal de monde aime attaquer d'habitude, et ne pas essayer de relire et comprendre pourquoi elle a été moinssée : c'est tellement plus simple d'insulter!

                            Quelqu'un aurait un lien ? Je cherche la publication de la spécification de la syntaxe du Français-2.0-alpha. Merci.

          • [^] # Re: En parlant de faille concernant une bibliothèque partagée...

            Posté par . Évalué à 2.

            sur une linuxmint 17.1, en l'absence de tout patch récent de la glibc (2.40) après avoir compilé et lancé GHOST, j’obtiens le message "not vulnérable". J'ai loupé un épisode?

  • # Qu'en pense ulrich?

    Posté par . Évalué à 1.

    "You don't pay me" ou "fuck you"?

    Deuxieme lance de troll subtile: pbpg quitte ms, commence a bosser sur linux, et v'la t'y pas qu'on a faille critique sur faille critique. D'aucuns y verraient un lien de cause a effet, mais on dirait qu'ils seraient mal intentionnes.

    Allez, je finit sur le combo finishing move: mais je croyais que grace au libre, yavait plein d'yeux pour relire le code et que donc yavait pas de failles?

    Linuxfr, le portail francais du logiciel libre et du neo nazisme.

    • [^] # Re: Qu'en pense ulrich?

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

      Il en penserait que c'est corrigé depuis plus d'un an et demi dans la version 2.18 publiée le 12 août 2013 (http://www.gnu.org/software/libc/).

      Tes trolls ne sont pas très frais.

    • [^] # Re: Qu'en pense ulrich?

      Posté par . Évalué à 2.

      bosser chez amazon ca veut donc dire bosser sous linux?

      • [^] # Re: Qu'en pense ulrich?

        Posté par . Évalué à 4.

        Si c est sur la partie AWS d'amazon, il y a de très grandes chances que oui.

      • [^] # Re: Qu'en pense ulrich?

        Posté par . Évalué à 8.

        Du tout, je fais du developpement sur XBox One en fait. On va migrer nos racks de serveurs en racks de consoles de jeux.

        • [^] # Re: Qu'en pense ulrich?

          Posté par . Évalué à 10.

          Tapettes. Nous on a achete 2 palettes d'iphone 6 plus, et on les a colle au mur.
          Le plus chiant c'est qu'il faut un gars au datacenter pour tapper le pin code quand on veut faire des mises a jour, mais la facture d'electricite a vachement diminue.
          L'autre probleme c'est que quand att est en carafe, le site est hors ligne.

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

  • # Les paquets corrigés chez Debian

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

    Les versions des paquets corrigés : https://security-tracker.debian.org/tracker/CVE-2015-0235

  • # DebConf '14

    Posté par (page perso) . Évalué à 2. Dernière modification le 30/01/15 à 22:03.

    Cette faille ressemble à ce dont parlait Linus Torvalds à DebConf '14, non?
    https://www.youtube.com/watch?v=1Mg5_gxNXTo (à 1h09)

    EDIT: non, en fait: http://googleprojectzero.blogspot.fr/2014/08/the-poisoned-nul-byte-2014-edition.html

    blog.rom1v.com

Suivre le flux des commentaires

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