L’équipe Qualys Threat Research Unit a découvert une importante faille de sécurité (CVE-2023-4911) dans la bibliothèque C de GNU. Elle peut provoquer un dépassement de mémoire tampon qui, exploité, peut conduire par escalade de privilèges à la récupération des droits administrateurs dans une partie des distributions Linux.
La bibliothèque C de GNU, appelée glibc, est chargée de fournir des fonctions essentielles au système, notamment les appels comme open, malloc, printf, exit, servant aux applications. Dans cette bibliothèque, le chargeur dynamique est responsable de la préparation et de l’exécution des programmes.
La faille réside dans la manière dont est traitée la variable GLIBC_TUNABLES, donnant son nom à la vulnérabilité, en référence aux Looney Tunes. Elle doit cependant être exploitée localement. La faille a été exploitée avec succès sur Debian 12 et 13, Ubuntu 22.04 et 23.04, et Fedora 37 et 38. Les chercheurs notent qu’Alpine Linux, par son utilisation de musl libc, n’est pas concernée.
Des correctifs ont été émis pour les autres. Il est recommandé de mettre à jour les installations aussi rapidement que possible.
Commentaires (55)
#1
Ouf, je viens juste de mettre à jour toutes mes machines.
Par contre, niveau exploitation locale, j’ai quelques doutes. Un simple module joomla bien ficelé peut tout à fait exploiter la faille non?
#2
Quel ne N° de CVE ?
#2.1
CVE-2023-4911, je viens de l’ajouter dans le texte
#3
Merci !
Ubuntu 22.04 : les correctifs ont été mis en ligne le 4 octobre dernier.
#4
Je me disais bien qu’il y avait drôlement beaucoup de mises à jour ce matin sur mes debian …
#4.1
Passage en 12.2 ;)
#4.2
Le patch libc6 est déployé sur Debian depuis au moins une semaine.
#5
Curieux d’avoir des nouvelles de ceux qui pondent des containers sans suivi.
Alors oui, c’est souvent Alpine par défaut. Mais les autres? Les distribs “je m’en fous”.
#5.1
Ah ça clairement c’est un des gros problèmes modernes…
Note que tu vas avoir exactement le même problème avec les flatpak/snap…
#5.2
Je ne sais pas si c’est de la modernité que de coller cela à toutes les sauces. Ça devrait rester le mal nécessaire d’applicatifs donnant peu confiance qu’il faut border… ou de vieux trucs plus maintenus mais restant parfois utiles, qui ne fonctionneraient pas sans cela sur une distro à jour.
En réalité, le concept a été violé pour se retrouver utilisé afin de permettre le véritable alignement de planètes de dépendances mal gérées (voir totalement évitables) d’applicatifs codés vite fait mal fait…
#5.4
#5.3
Il me semble, mais je ne sais pas si c’est le cas en théorie sur Docker (en pratique, il y a surement des failles), l’un des principes de la conteneurisation, c’est d’isoler l’exécution du container du reste du système. Il pourrait se passer ce qu’il veut dans le container, son interaction avec le système hôte est limitée.
#5.5
Attention, si on n’y prend pas garde les process des containers sont en root dans le container, et en root sur l’OS.
Donc en cas de faille dans le process, avec de “mauvaises” images sur un “mauvais” container, c’est root direct !
Et le nombre d’images avec des processus root est encore important, et le nombre de containers qui ne “remappe” pas root vers un autre user sont nombreux (install par défaut avec docker)…
Par défaut, le niveau d’isolation peut facilement sembler perfectible.
#5.6
Les Dockerfile sans instruction
USERsont effectivement trop fréquents. Alors que ça fait partie des alertes soulevées par la plupart des analyseurs de code.#5.7
Avant de parler conteneurs, parlant des machines virtuelles, voire de machine physiques.
Certaines entités ne les mettent juste pas à jour.
#5.8
Les vieux serveurs sans mises à jour (même celle en mode étendue) peut être le résultat d’une exigence client. Pour ce genre de cas, je préconise une DMZ avec un antivirus réglé sur paranoïaque avec mise à jour de la base de signature toutes les 2 heures.
#6
Effectivement, rien à voir avec la faille mentionnée.
À noter qu’il y a aussi des nouvelles versions pour les 2 versions de Debian antérieures (Bullseye & Buster).
Ouaip, le nombre de personnes qui se pensent protégées car “Docker, c’est magique…”, d’autant plus qu’il y a des failles de sécu qui permettent de passer outre la conteneurisation.
#7
Sinon pour ceux qui se posent la question pour suse/opensuse:
https://www.suse.com/security/cve/CVE-2023-4911.html
En gros Suse/opensuse non concerné.
Tumbleweed c’est corrigé glibc >= 2.38-4.1
#7.1
Merci bien, je cherchais l’info dans les mailing lists
#8
Notez tout de même que la plupart des grosses distrib’ ont publié les correctifs plusieurs jours avant la news / annonce.
ce qui n’est généralement pas le cas pour les OS propriétaires
#8.1
Il a quand même fallu 14 commentaires pour ce troll semi déguisé. Toujours la même rengaine
Quand le process est respecté ça se passe bien chez l’ensemble des OS qu’ils soient propriétaire ou pas. Il y a des patch d’urgence quand c’est nécessaire.
#8.2
La capacité à ne pas vouloir comprendre et à tout prendre de travers m’épate toujours.
En partant du prérequis de base que l’utilisateur effectue les mises à jour au fur et à mesure des publications, l’élément à surveiller est la vitesse de publication des correctifs. Et avant la dite publication, la base de signature antivirus est sensée protéger à minima le système.
Et dans certains cas, le correctif est publié avant les mises à jour des bases antivirus.
Sauf que :
Donc oui, il n’y a pas de système infaillible, mais il y a moyen en faisant attention d’être à minima exposé.
et il a (encore) fallu tout un paragraphe pour démonter une bêtise écrite en une phrase
#9
quand même, “la faille doit être exploité localement” tous les PC de la maison ont un bios / EFI avec mot de passe et tout bloqué sauf démarrage sur le disque dur et l’OS protégé par mot de passe alors pour entrer localement… et au cas ou j’ai aussi un manche pioche à portée de main…
#10
L’isolation fournie pas les containers c’est pour augmenter la robustesse de la conception (“Low Coupling, High Cohesion”) et pas augmenter la cyber-résilience.
Oui l’interaction est limitée… Mais pas au point de garantir la sécurité globale du système si un container a été compromis.
#11
Un exemple :
https://threatpost.com/azurescape-kubernetes-attack-container-cloud-compromise/169319/
#12
En couplant ça par exemple avec un electron pas mis à jour suite à la faille webp, ça peut-être plus facile que tu ne le penses…
La plupart des attaques avec exfiltration de données est par exploitation locale, même sur des postes protégés…
#13
Elle est sortie quand la Debian 13 ? :fumer
Je suis encore sur la 11 !
:
#13.1
Je suis aussi curieux de savoir. J’ai loupé l’info. Pour une fois que ça traine pas, on aurait pu nous mettre au courant…
#13.2
Je crois que c’est la version testing
La news pour la 12 c’était le 15 Juin
#14
hello quelqu’un sais si les nas synology sont impactés ?
#15
C’est bien ça, actuellement Debian 13 est la “testing”, la 12 la “stable”, la 11 la “oldstable” et la 10 “oldoldstable”, et sid la rolling release à utiliser si on aime les trucs tout pétés…
https://wiki.debian.org/DebianReleases
#16
Ça fait 23 ans que je tourne en sid, c’est vraiment très très rarement tout pété.
#17
“Elle doit cependant être exploitée localement.”
C’est donc une faille importante, logique.
#18
#19
J’espère que ça rappellera aux personnes qui fantasment sur la sécurité “by design” de Linux que c’est juste un fantasme et que celle-ci n’est jamais absolue.
#19.1
J’avoue que sur ce coup, j’ai du mal à me sentir menacé.
#19.2
Ce n’est pas une question de se sentir menacé ou non par cette faille précise, mais d’être conscient que tout système est faillible et que sa sécurité IT ne peut reposer sur une croyance comme on peut malheureusement trop souvent le lire ou l’entendre.
#19.3
Pour rappeler ça, je pense qu’il serait opportun de choisir une faille réellement dangereuse.
#19.4
C’est un fantasme ça, du moment qu’un OS est connecté sur un réseau, il a des failles exploitables. Il n’y a aucun design qui permette d’avoir 0 faille, si ce n’est d’avoir un système totalement isolé…
Sachant qu’en plus, on a rarement des OS dans aucune applications dessus, que ce soit du service ou autre, qui rajoute leur énorme lot de failles, c’est clairement de l’ignorance que de se penser intouchable parce qu’on est sur Linux
Après il faut toujours que l’exploitation de la faille soit rentable, donc, c’est la qu’on fait une analyse de risque :p (27001 si tu nous regarde…)
#20
Ah ben c’est un heureux hasard, parce que d’habitude je n’installe jamais des versions bêta
des distributions, ben là hier j’me suis dit, dans ma toute petite tête : qu’est-ce que tu as à perdre après tout ? en effet, vu que je ne peux pas utiliser Linux pour des travaux “sérieux” (NB : pour moi, “sérieux” veut toujours dire : Musique ! Vu que c’est toute ma vie…)
Il se trouve que depuis une semaine, en parallèle de Kubuntu 23.04, je teste aussi Fedora 38 - et pas plus tard qu’hier, j’ai donc tenté le coup de passer à la 39 bêta - oui c’est plus fort que moi - en suivant très exactement, à la lettre de la virgule près, le doigt sur la couture du pantalon, ce mode d’emploi… et résultat, ça marche super-bien !
Aucun bug majeur à rapporter ! (*)
Après lecture attentive de cet article, je me dis que j’ai bien fait ! Et après vérification, je peux vous dire que glibc a bien été updatée à la version 2.38 - 7.fc39 et que la faille a été déjà patchée, en voici la preuve : voir ICI et surtout ICI.
…
(*) …A part, mais je ne sais pas si c’est lié au patch, lorsque je tente de lancer manuellement l’install d’un jeu, j’ai cette erreur :
Sur un deuxième jeu (manque de bol, j’en ai que deux pour tester, tout ce qui me reste d’un “Humble Bundle” acheté il y a des années et égaré…
), c’est : “execvp” à la place de “execve”. Est-il possible que ce soit une des conséquences du patch qui comble la faille CVE-2023-4911 ? …Ou c’est moi ? 
#21
La faille donne accès au root; mais si il est désactivé est-ce que la faille est exploitable ?
Simple question, mon os est à jour.
#22
Absolument. Mais on peut quand même le lire régulièrement.
#23
Oui, puisque la faille utilise un binaire qui a le bit suid root. Si ton compte root est désactivé, c’est que tu ne l’utilise qu’au travers de sudo, qui est justement un bon exemple de binaire suid root.
Si ton système est à jour, alors tu as la correction, donc ça ne craint plus rien.
#24
Aucun rapport. La faille est un buffer overflow dans le parsing des options de réglages de la libc qui sont passées par une variable d’environnement. Le patch est juste un blindage du parsing, sans aucun changement fonctionnel. Là, ton erreur c’est un binaire qui cherche à charger un autre binaire, et ne le trouve pas.
#25
Dit-il.
Parler d’antivirus, une technologie des années 90, pour parler des protections actuelles, c’est beau.
C’est faux, on te l’a déjà expliqué, notamment ici : https://www.nextinpact.com/lebrief/72298/un-hebergeur-danois-victime-dun-ransomware-majorite-nos-clients-ont-donc-perdu-toutes-leurs-donnees#comment/2149035
En effet, cette “capacité à ne pas vouloir comprendre et à tout prendre de travers m’épate toujours.”.
ça fait bien longtemps que ça ne marche plus comme ça …
Bravo, c’est la conclusion des formations régulières en sécurité à destination des collaborateurs.
En effet, tellement de bêtises, il faudrait se mettre un peu -beaucoup- à jour, et arrêter de répandre ces croyances à la moindre occasion.
#25.1
On va zapper le monceau de bullshit, juste pour essayer de comprendre l’intérêt du lien que tu viens de donner !?
On parle de failles sur les OS, un ransomware peut s’attaquer à une machine saine juste en passant par la faille sociale. Quel rapport avec les trous logiciels ?
Concernant les mises à jour, il convient, avec la complexité actuelle des logiciels, de reprendre les fondamentaux (encore faut il les connaître et savoir les manipuler) et de se poser les bonnes questions. Les palettes de procédures d’exploitation teintées de conservatisme morbide et les outils tout-en-un qui font papa-maman « pour-ton-bien » ne sont pas des solutions acceptables aujourd’hui.
Il y a 2 postures possibles :
La différence entre ces 2 postures est une différence d’objectif : une est orientée « comment », l’autre est orientée « pour quoi ».
Tu peux me créditer de troll, de machine à bullshit, tout ce que tu veux … mais ça fait pas mal d’années que je fais de la sécu / veille techno / développement / architecture pour connaître les technologies et les habitudes utilisateur et devoir jongler avec les capacités / limitations des uns et des autres au quotidien. Par expérience, les approches pragmatiques sont, malheureusement, les seules qui fonctionnent sur le long terme.
#26
J’essaie de savoir ce que font exactement ces deux binaires (d’après les forums que j’ai consulté, ces deux exécutables sont bien présents sur Ubuntu, mais, il semblerait, pas sur Fedora…
Pas évident de comprendre tous ça pour un ignorant comme moi, mais, d’après ces deux vénérables pages de manuel, il apparaît que ces deux programmes, inclus dans certains packages de glibc, soient utilisés par les devs… pour exécuter des exécutables, tout en leur passant des arguments divers et variés.
Je suppose que ça doit bien servir pour des tests, mais il semblerait que Fedora ne les ait pas inclus, peut-être pour des raisons de sécurité ? Enfin voilà, pardon pour ce HS, mais mon ch’ti cerveau ne cesse de poser en permanence des dizaines de milliers de questions, dont je n’ai absolument pas la réponse…
#27
Non, execve et execvp ne sont pas des binaires (qui manqueraient chez toi), ce sont les fonctions de chargement du binaire suivant. Mais quel était le binaire cherché ? On ne le sait pas avec le message que tu as posté.
#27.1
C’est très simple, j’ai retrouvé deux très vieux jeux - les seuls que j’ai pour Linux - que j’ai essayé d’installer. Lorsque je lance leur binaire d’installation (j’ai vérifié leurs droits, ils sont bien exécutables avec les droits : r-w-x pour l’utilisateur), le message d’erreur indiqué plus haut s’affiche :
ou encore :
Comme j’ai appris que ces deux “exec” sont livrés avec certaines versions de Glibc, j’ai fait le rapprochement avec le sujet de l’article.
J’ai cherché sur la totalité du disque ou j’ai installé Fedora, et effectivement, il semblerait qu’ils n’existent pas… ou plus ?
#28
Reprenons : dans tes messages, le “execve:” ou “execvp:” ne veulent pas dire que ces fichiers n’ont pas été trouvés. Ils veulent dire que ces fonctions n’ont pas trouvé un certain fichier (on ne sait pas lequel). Ce message est affiché par execve ou execvp.
Tu peux les chercher tant que tu veux sur ton disque, ce sont des fonctions de la libc, et ta libc les contient, garanti à 100%.
Donc tout ce qu’on peut en conclure, c’est que ton binaire a chercher à en exécuter un autre, mais on ne sait pas lequel. On pourrait avoir plus d’infos à coup de strace, mais je n’ai pas l’impression que tu sois en mesure de comprendre le résultat d’un strace.
#29
Voici le résultat de la commande : “sudo strace “/-/-/-/-/Capsized/capsized-12212015-bin” -v :
(Remplace les tirets par des noms de dossiers - Note : la balise “< code >” ne marche pas ici, donc il est possible que ça ne restitue pas bien le résultat)
execve(“/-/-/-/-/-/capsized-12212015-bin”, [“/-/-/-/-/Cap”…, “-v”], 0x7ffc8a1d3198 / 19 vars /) = -1 ENOENT (Aucun fichier ou dossier de ce type)
strace: exec: Aucun fichier ou dossier de ce type
+++ exited with 1 +++
Bon là je suppose qu’il me manque
une case… euh un ou plusieurs paramètre(s) pour que la commande strace soit vraiment utile…#30
Ça veut dire que le “/-/-/-/-/-/capsized-12212015-bin” (celui de la ligne execve) n’a pas été trouvé.
#31
Il me semble qu’en fait, lorsque je le lance, ce prog, nommé “capsized-xxx.bin” (un vieux jeu) se met à la recherche d’un autre fichier, d’un dossier ou d’une commande qu’il ne trouve pas, ce qui donne le résultat décrit plus haut : il affiche l’erreur “no such file or directory”.
Cette erreur est donc émise par l’exécutable “capsized-xxx” lui-même. Mais bon, t’embête pas, je vais essayer de comprendre comment fonctionne strace (merci de me l’avoir indiqué au passage !) afin de déterminer quelle est la véritable erreur.
C’est juste la première fois que j’essaie d’installer manuellement - je veux dire, sans passer par le gestionnaire de packages officiel de la distri, ni par aucune autre béquille - un programme externe à la distri en question, dans ce cas il s’agit d’un installeur Linux générique qui est censé fonctionner quelque soit la distri choisie.
Je retiens donc de notre conversation que execv* n’est pas un exécutable, mais un ensemble de commandes en language C, provenant de la librairie (Gnu ou pas) libc incluse dans la plupart des distris.
…et je te remercie vraiment pour toutes ces infos, exactement le genre d’infos que je recherche tous les jours, avec gourmandise…
#32
Une faille locale, sauf cas particulier, j’ai du mal à voir également.
Il faut avoir un serveur public au minimum pour que ce soit un souci.
#33
Donc si j’ai bien compris, pour l’exploiter il faut:
Sans regarder plus en détail, si on a un shell et un exemple de valeur ça semble trivial à exploiter. J’imagine qu’un autre scénario est d’exécuter un programme ou script que l’on suppose sûr). De manière distante (ex: service web), il faudrait que l’attaquant trouve un moyen d’assigner la variable et d’exécuter un programme suid.