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 sirrus . Évalué à -10. Dernière modification le 27 janvier 2015 à 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 Dabowl_75 . É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 Zenitram (site web personnel) . Évalué à 10. Dernière modification le 27 janvier 2015 à 17:39.
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 Dabowl_75 . É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 Zenitram (site web personnel) . É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 Dabowl_75 . É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 Sufflope (site web personnel) . Évalué à 3.
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 thargos . É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 Misc (site web personnel) . É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 Antoine . Évalué à 10.
Tu veux dire qu'ils leveragent des synergies structurantes pour des partenariats win-win ?
[^] # Re: Prems LOL
Posté par N-Mi . Évalué à 9.
FOUTAISES !!!
[^] # Re: Prems LOL
Posté par Raoul Volfoni (site web personnel) . É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 Tonton Th (Mastodon) . Évalué à 4.
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 ?
[^] # Re: Prems LOL
Posté par Fabrice Devaux . É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 jjl (site web personnel) . É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 Bapt (site web personnel) . Évalué à 2.
On n'a vraiment pas la même expérience du support RedHat :)
[^] # Re: Prems LOL
Posté par 2PetitsVerres . É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 Sufflope (site web personnel) . É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 Albert_ . Évalué à -10.
Pincer moi, Zenitram qui defend le libre et linux…
[^] # Re: Prems LOL
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 27 janvier 2015 à 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 lasher . Évalué à 10.
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.
En fonction du site où tu officies a priori, donc. :-) ↩
[^] # Re: Prems LOL
Posté par Astaoth . Évalué à 10.
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.
Emacs le fait depuis 30 ans.
[^] # Re: Prems LOL
Posté par TImaniac (site web personnel) . Évalué à -2.
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 Albert_ . É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 TImaniac (site web personnel) . Évalué à 0.
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 Albert_ . É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 TImaniac (site web personnel) . É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 legranblon (site web personnel) . É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 dyno partouzeur du centre . Évalué à 10.
Il suffit de supprimer la libc:-)
[^] # Re: Quick fix
Posté par Dabowl_75 . Évalué à 6.
et comme ça on n'aura plus besoin de rajouter GNU à linux mais on ne pourra plus l'utiliser :-)
[^] # Re: Quick fix
Posté par Astaoth . Évalué à 10.
Bof, bientôt on aura la systemd-libc, alors pas de soucis pour virer la glibc.
Emacs le fait depuis 30 ans.
[^] # Re: Quick fix
Posté par IckyThump . Évalué à 3.
La glibc: http://en.wikipedia.org/wiki/C_standard_library#Implementations
[^] # Re: Quick fix
Posté par Parleur . Évalué à 5.
Ho, bah si on les supprime toutes, on devrait s'épargner encore plus de problèmes. :)
[^] # Re: Quick fix
Posté par Tonton Th (Mastodon) . Évalué à 10.
http://www.pafoo.net/uninstallglibc/uninstglibc.html
# Pas 'dredi
Posté par karchnu . É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 aiolos . É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.
[^] # Re: Pas 'dredi
Posté par Anonyme . Évalué à 5.
Vu la liste des "mitigating factors", c'est pas non plus aussi critique que tous les messages alarmants le laissent croire:
http://www.openwall.com/lists/oss-security/2015/01/27/9
[^] # Re: Pas 'dredi
Posté par Misc (site web personnel) . Évalué à 2.
Ouais, le vrai risque est de voir qu'une fonction oublié ou obscur pose souci. Mais pour le moment, c'est pas la catastrophe non plus.
# trop tôt
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 27 janvier 2015 à 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 benoar . É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 Anonyme . É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 TImaniac (site web personnel) . Évalué à 6.
Le voilà :)
[^] # Re: trop tôt
Posté par Tonton Th (Mastodon) . Évalué à 6.
OMFG, mais ce n'est pas un prompt Unix classique !
[^] # Re: trop tôt
Posté par IckyThump . Évalué à 3.
Non, c'est un shoot'em up à scrolling horizontal.
[^] # Re: trop tôt
Posté par 🚲 Tanguy Ortolo (site web personnel) . É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 octane . Évalué à 4.
export PS1=">_ "
'service
[^] # Re: trop tôt
Posté par pasBill pasGates . É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.
[^] # Re: trop tôt
Posté par Zenitram (site web personnel) . Évalué à 1.
Elle marque le nom de sa boite :
http://www.frsag.org/pipermail/frsag/2015-January/005722.html
"veronique Loquet - AL'X Communication"
1/ c'est un PR de chez PR, avec plein de langue de bois et un zest d'infos techniques, pas grand chose de journalistique dans son post,
2/ Elle l'assume.
Note : je ne renie pas son implication, je n'en sais rien, j'analyse juste ce PR.
[^] # Re: trop tôt
Posté par Eric P. . Évalué à 4.
Surtout elle assume etre PR pour Qualys, ce qui confirme la supposition de benoar:
http://www.alx-communication.com/reference/26/qualys-inc
Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.
# Sans le bullshit marketing
Posté par benoar . É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 Zenitram (site web personnel) . Évalué à 6. Dernière modification le 27 janvier 2015 à 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 Troy McClure (site web personnel) . Évalué à 10.
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 patrick_g (site web personnel) . É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 octane . É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 pasBill pasGates . É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 Anonyme . É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 Renault (site web personnel) . É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 Dabowl_75 . É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: ksh93100000000 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 Kioob (site web personnel) . É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 claudex . É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 pyknite . Évalué à 2.
"Dans le doute, reboot!"
[^] # Re: En parlant de faille concernant une bibliothèque partagée...
Posté par ®om (site web personnel) . Évalué à 5.
Après une mise à jour sans reboot sur Debian Wheezy, j'ai compilé
GHOST.cfourni ici puis lancé l'exécutable :Ç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 Anonyme . É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 Babelouest (site web personnel) . É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 Sufflope (site web personnel) . É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 Babelouest (site web personnel) . É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 Anonyme . É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 Moonz . É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 Zenitram (site web personnel) . Évalué à 5. Dernière modification le 28 janvier 2015 à 09:44.
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 Albert_ . É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 Albert_ . É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 Zenitram (site web personnel) . Évalué à 4.
Faut vraiment répondre?
Bon vite fait :
Euh… Tu as lu?
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.
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.
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 gnx . Évalué à 1.
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 oliviergiraud . É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?
[^] # Re: En parlant de faille concernant une bibliothèque partagée...
Posté par oliviergiraud . Évalué à 3.
je me corrige tout seul: la version 2.4 n'est pas touchée. Ca m'apprendra à lire les posts en diagonale
# Qu'en pense ulrich?
Posté par groumly . É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 Olivier Serve (site web personnel) . É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 Albert_ . Évalué à 2.
bosser chez amazon ca veut donc dire bosser sous linux?
[^] # Re: Qu'en pense ulrich?
Posté par Prosper . É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 pasBill pasGates . É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 groumly . É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 Frédéric Massot (site web personnel) . Évalué à 1.
Les versions des paquets corrigés : https://security-tracker.debian.org/tracker/CVE-2015-0235
# DebConf '14
Posté par ®om (site web personnel) . Évalué à 2. Dernière modification le 30 janvier 2015 à 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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.