GNU/Linux en sueur avec cette faille RCE critique
-
On a du lourd aujourd’hui, et pas dans le bon sens du terme. Une faille de sécurité critique vient d’être découverte sur les systèmes GNU/Linux, et elle fait l’effet d’une bombe. On parle d’une vulnérabilité permettant une exécution de code à distance (RCE) non authentifiée. Autant dire que c’est le genre de truc qui donne des sueurs froides aux admins sys ! Déjà que ça sent pas mal la transpi là dedans, ça va pas s’arranger.
Cette faille a été découverte il y a environ 3 semaines par le chercheur en sécurité Simone Margaritelli et elle affecte potentiellement tous les systèmes GNU/Linux. Oui, vous avez bien lu : TOUS.
Cette vulnérabilité a d’ailleurs été évaluée avec un score CVSS de 9.9 sur 10. Pour ceux qui ne sont pas familiers avec cette échelle, disons simplement que c’est l’équivalent d’un 19.8/20 en sécurité informatique. Et c’est pas une bonne note.
Le plus inquiétant dans cette histoire, c’est que cette vulnérabilité serait présente dans le code depuis plus d’une décennie. Pendant que vous jouiez tranquillement à Minecraft durant votre enfance, ou que vous codiez votre premier “Hello World”, cette faille était là, tapie dans l’ombre, attendant son heure.
Mais alors pourquoi est-ce si compliqué de corriger cette faille ?
Eh bien, il semblerait que le problème soit plus complexe qu’il n’y parait. D’après Margaritelli, il faudrait au moins 3 CVE (Common Vulnerabilities and Exposures) pour couvrir tous les aspects de cette vulnérabilité. Ça en fait du boulot !
Bien sûr, comme d’hab, cette situation soulève des questions importantes sur la gestion des vulnérabilités dans le monde open source : Comment peut-on améliorer le processus de détection et de correction des failles ? Comment s’assurer que les développeurs prennent au sérieux les rapports de sécurité ?
Il faut dire que la communication autour de cette vulnérabilité n’a pas été des plus fluides. Margaritelli a d’ailleurs exprimé sa frustration face à certains développeurs qui semblaient plus enclins à défendre leur code qu’à reconnaître le problème.
Mais alors QUE FAIRE ?
Malheureusement, à l’heure où j’écris ces lignes, il n’y a toujours pas de correctif disponible. Les développeurs sont en plein branle-bas de combat pour trouver une solution, mais ça prend du temps. Et pendant ce temps-là, nos systèmes restent vulnérables, même si rassurez-vous, ce n’est pas le genre de faille si facile à exploiter. Ça demande beaucoup d’expertise donc pour le moment, ce n’est pas encore à portée du premier script kiddy qui passe.
En attendant le patch salvateur, voici quelques conseils pour limiter les risques :
- Gardez un œil sur les annonces officielles de votre distribution Linux
- Assurez-vous que vos firewalls sont correctement configurés
- Limitez au maximum l’exposition de vos systèmes sur Internet
- Soyez prêts à déployer le correctif dès qu’il sera disponible
Cette histoire, aussi stressante soit-elle, n’est qu’un rappel que la sécurité est un combat de tous les instants. Restez sur vos gardes, gardez vos systèmes à jour, et n’oubliez pas :
dans le doute, sudo rm -rf /* … Non, je déconne, ne faites JAMAIS ça !
Sur ce, je retourne surveiller mes logs.
Merci à Nicolas pour le partage !
– Sources :
https://threadreaderapp.com/thread/1838169889330135132.html
https://korben.info/faille-rce-critique-linux-cauchemar-admins.html
-
Bien sûr, comme d’hab, cette situation soulève des questions importantes sur la gestion des vulnérabilités dans le monde open source
Qu’est-ce que ce « comme d’hab » vient faire là M. Korben ? Le caractère open source d’un programme n’a rien avoir avec « la gestion des vulnérabilités ». Au pire la caractère « libre », et donc financier, peut-être.
Perso cette faille me fait très peur, mais j’attendrai d’avoir les détails CVS ainsi que les avis et explications de tous les partis concernés avant de juger cette « gestion des vulnérabilités ».
-
Bien sûr, comme d’hab, cette situation soulève des questions importantes sur la gestion des vulnérabilités dans le monde open source
Qu’est-ce que ce « comme d’hab » vient faire là M. Korben ? Le caractère open source d’un programme n’a rien avoir avec « la gestion des vulnérabilités ». Au pire la caractère « libre », et donc financier, peut-être.
Perso cette faille me fait très peur, mais j’attendrai d’avoir les détails CVS ainsi que les avis et explications de tous les partis concernés avant de juger cette « gestion des vulnérabilités ».
@kemkem a dit dans GNU/Linux en sueur avec cette faille RCE critique :
Bien sûr, comme d’hab, cette situation soulève des questions importantes sur la gestion des vulnérabilités dans le monde open source
Qu’est-ce que ce « comme d’hab » vient faire là M. Korben ? Le caractère open source d’un programme n’a rien avoir avec « la gestion des vulnérabilités ». Au pire la caractère « libre », et donc financier, peut-être.
Perso cette faille me fait très peur, mais j’attendrai d’avoir les détails CVS ainsi que les avis et explications de tous les partis concernés avant de juger cette « gestion des vulnérabilités ».
Je comprends tes inquiétudes et ton point de vue, mais à titre personnel, je pense que le caractère open source/libre d’un programme a tout de même un impact sur la gestion des vulnérabilités. La transparence du code permet à un plus grand nombre de développeurs et de chercheurs de repérer les failles, et les corrections peuvent parfois être plus rapides (ou pas) grâce à la communauté.
Cependant, il y a aussi des choses à souligner comme la responsabilité. Contrairement aux logiciels propriétaires, où une entreprise unique est responsable de la gestion des correctifs, la responsabilité dans l’open source peut être partagée entre plusieurs contributeurs. Cela peut parfois ralentir la prise en charge d’une vulnérabilité critique.
Il faut aussi prendre en compte la disponibilité des ressources. Les projets open source, surtout les plus petits, peuvent manquer de ressources financières ou humaines pour répondre rapidement aux vulnérabilités. Tous les projets n’ont pas une communauté aussi active ou réactive.
Comme soulignez et on le voit bien ici, la gestion des vulnérabilités reste un défi, car la réactivité peut varier selon l’ampleur et l’organisation du projet.
Concernant cette faille, je pense aussi qu’il est important d’attendre plus d’informations avant de juger.
V:\> █░░ SPR3AD TH3 C0D3 ░░█ ✌(◕‿-)✌
╚═ Admin, Dev et auteur de la plupart des bugs de PW… -
@kemkem a dit dans GNU/Linux en sueur avec cette faille RCE critique :
Bien sûr, comme d’hab, cette situation soulève des questions importantes sur la gestion des vulnérabilités dans le monde open source
Qu’est-ce que ce « comme d’hab » vient faire là M. Korben ? Le caractère open source d’un programme n’a rien avoir avec « la gestion des vulnérabilités ». Au pire la caractère « libre », et donc financier, peut-être.
Perso cette faille me fait très peur, mais j’attendrai d’avoir les détails CVS ainsi que les avis et explications de tous les partis concernés avant de juger cette « gestion des vulnérabilités ».
Je comprends tes inquiétudes et ton point de vue, mais à titre personnel, je pense que le caractère open source/libre d’un programme a tout de même un impact sur la gestion des vulnérabilités. La transparence du code permet à un plus grand nombre de développeurs et de chercheurs de repérer les failles, et les corrections peuvent parfois être plus rapides (ou pas) grâce à la communauté.
Cependant, il y a aussi des choses à souligner comme la responsabilité. Contrairement aux logiciels propriétaires, où une entreprise unique est responsable de la gestion des correctifs, la responsabilité dans l’open source peut être partagée entre plusieurs contributeurs. Cela peut parfois ralentir la prise en charge d’une vulnérabilité critique.
Il faut aussi prendre en compte la disponibilité des ressources. Les projets open source, surtout les plus petits, peuvent manquer de ressources financières ou humaines pour répondre rapidement aux vulnérabilités. Tous les projets n’ont pas une communauté aussi active ou réactive.
Comme soulignez et on le voit bien ici, la gestion des vulnérabilités reste un défi, car la réactivité peut varier selon l’ampleur et l’organisation du projet.
Concernant cette faille, je pense aussi qu’il est important d’attendre plus d’informations avant de juger.
@evilsocket a dit dans Review locking/multi-threading implementation :
@michaelrsweet are you for fucking real man? Do you think people are stupid?
Tant de Violence…
cups étant banni de mes machines depuis toujours, je suis un peu rassuré.
-
V:\> █░░ SPR3AD TH3 C0D3 ░░█ ✌(◕‿-)✌
╚═ Admin, Dev et auteur de la plupart des bugs de PW… -
Dire que dés le début un simple message conseillant aux gens de désactiver l’inutile
cups-browsedaurait suffit à appaiser tout le monde. Maintenant Simone va s’en prendre plein la gueule pour rien. Et c’est d’autant plus dommage que la faille en question est quand même énorme, même si il n’est pas si évident d’y accéder. -
Pour résumer, exploiter simplement cette faille revient à aller déposer physiquement une imprimante dans les bureaux de la cible et de la brancher au réseau. Préalablement on aura injecté dans celle-ci un PPD malveillant pour qu’il soit automatiquement injecté dans les environnements Linux de la cible à condition que le démon cups-browsed soit activé. Et là on aura la main sur les machines.
-
Infiltrer physiquement la cible n’est pas forcément nécessaire, mais effectivement les conditions pour mener cet exploit sont rarement rassemblées. Ce qui ne l’empèche pas d’être en soit une faille critique ceci dit. Juste que tout ce tappage était peut-être inutile.
-
Bonjour, le message sera un peu long, mais traduit d’une page !
Correctif de vulnérabilité d’exécution de code à distance CUPS disponibleQuatre identifiants CVE ont été attribués et forment ensemble une chaîne d’exploitation à fort impact autour de CUPS : CVE-2024-47076 , CVE-2024-47175 , CVE-2024-47176 et CVE-2024-47177 .
L’équipe de sécurité de Canonical a publié des mises à jour pour les packages cups-browsed, cups-filters, libcupsfilters et libppd pour toutes les versions d’Ubuntu LTS sous support standard. Les mises à jour corrigent CVE-2024-47076, CVE-2024-47175, CVE-2024-47176, tandis que CVE-2024-47177 est corrigé par les 3 autres vulnérabilités en cours de correction. Des informations sur les versions concernées peuvent être trouvées dans les pages CVE liées ci-dessus. Si l’un de ces éléments est installé, notre recommandation est de le mettre à jour dès que possible. Lisez la suite pour en savoir plus sur les détails. Des mises à jour de sécurité pour les versions ESM seront publiées prochainement.
Comment fonctionne la chaîne d’exploitÀ la base, la vulnérabilité est exploitée en incitant CUPS à générer un fichier PPD (PostScript Printer Description) contrôlé par un attaquant pour une imprimante contenant une commande arbitraire. Chaque fois que le prochain travail d’impression est envoyé à l’imprimante en question, la commande sera exécutée en tant qu’utilisateur lp (il s’agit de l’utilisateur sous lequel le démon CUPS s’exécute et, sauf autres vulnérabilités exploitables, n’aurait pas de privilèges élevés).
La génération du fichier PPD manipulé en premier lieu peut être réalisée de deux manières :
Sur le réseau local, mDNS peut être utilisé pour enregistrer automatiquement une nouvelle imprimante ou pour remplacer le fichier PPD associé à une imprimante existante. Cela nécessite que l'attaquant soit capable de générer les datagrammes de multidiffusion et de les faire atteindre le démon parcouru par cups (port 631). Le trafic multicast n’étant pas transmis sur Internet, le vecteur d’attaque est ici réduit, mais néanmoins considérable. Sur n'importe quel réseau, y compris Internet, un ancien protocole basé sur UDP peut être utilisé pour enregistrer une nouvelle imprimante avec un fichier PPD malveillant. Cela nécessite que l'attaquant soit capable d'envoyer un datagramme UDP au port 631, géré par cups-browsed, sur l'hôte cible. Un pare-feu (ou un routeur NAT) peut empêcher ce vecteur d'attaque.Qui est concerné
CUPS ou, plus précisément, cups-browsed est généralement installé sur les ordinateurs de bureau et les serveurs configurés comme serveurs d’impression. La chaîne d’exploit n’est terminée que si une tâche d’impression est envoyée. Ainsi, si vous n’imprimez jamais, aucune exécution de commande n’aurait pu avoir lieu, même si les packages vulnérables avaient été installés et qu’un acteur malveillant avait tenté l’exploit.
Nous recommandons à toute personne disposant des packages concernés d’appliquer la mise à jour de sécurité dès que possible. Les serveurs dépourvus de règles de pare-feu appropriées et les ordinateurs portables susceptibles de se connecter à des réseaux non fiables sont particulièrement exposés.
Comment s’adresserNous vous recommandons de mettre à niveau tous les packages, suivi d’un redémarrage du démon CUPS :
sudo apt update && sudo apt upgrade
sudo systemctl restart cups.serviceSi cela n’est pas possible, les composants concernés peuvent être ciblés :
sudo apt update && sudo apt install --only-upgrade cups-browsed cups-filters cups-filters-core-drivers libcupsfilters2t64 libppd2 libppd-utils ppdc
sudo systemctl restart cupsLa fonctionnalité de mise à niveau sans surveillance est activée par défaut à partir d’Ubuntu 16.04 LTS et versions ultérieures. Cette prestation :
Applique automatiquement de nouvelles mises à jour de sécurité toutes les 24 heures Si cette option est activée, les correctifs ci-dessus seront automatiquement appliqués dans les 24 heures Cependant, nous recommandons toujours de redémarrer le démon CUPS à l'aide de systemctl restart cups.serviceAtténuation
La protection la plus efficace consiste à appliquer les mises à jour de sécurité. Les mesures d’atténuation suivantes ont été étudiées, mais elles présentent des limites et peuvent provoquer des effets secondaires involontaires.
Pour les ordinateurs de bureau, la suppression du composant cups-browsed ou la désactivation des protocoles réseau affecteraient la capacité de détection des imprimantes réseau.
Pour les serveurs d’impression, la désactivation de la détection des imprimantes réseau peut être considérée comme une atténuation adéquate, car les imprimantes déjà configurées continueraient d’être disponibles, mais, sur les systèmes Ubuntu, la modification du fichier de configuration associé empêcherait les futures mises à niveau sans surveillance de se terminer correctement. Pour cette raison, nous ne recommandons pas cette approche. Si les mises à jour de sécurité ne peuvent pas être appliquées, vous ne devez suivre les étapes suivantes qu’en dernier recours et restaurer le fichier de configuration d’origine une fois les mises à jour appliquées.
Les étapes d’atténuation suivantes suppriment la capacité d’un serveur d’impression à détecter de nouvelles imprimantes réseau et à arrêter l’injection du fichier PPD malveillant :
Modifier /etc/cups/cups-browsed.conf Recherchez l’option de configuration BrowseRemoteProtocols Définissez l’option sur aucun (la valeur par défaut est « dnssd cups ») Redémarrez les tasses parcourues à l'aide de systemctl redémarrez les tasses parcouruesL’importance d’une divulgation coordonnée
Ces questions ont reçu beaucoup d’attention avant leur divulgation publique. Les vulnérabilités sont normalement discutées entre le journaliste, les projets concernés et les distributions Linux, telles qu’Ubuntu, sous embargo, afin que les mises à jour de sécurité puissent être préparées et publiées simultanément dans le cadre d’une divulgation coordonnée par tous les éditeurs de logiciels. Parfois, des informations peuvent fuir, ce qui peut mettre les utilisateurs en danger.
Nous encourageons chacun à considérer le bien commun. Dans ce cas, la date de divulgation coordonnée a dû être avancée, afin d’équilibrer la nécessité d’une préparation adéquate et de fournir des mises à jour dans les plus brefs délais. Cela a affecté notre projet de publier simultanément des mises à jour de sécurité pour toutes les versions d’Ubuntu, y compris ESM.
Lors de réponses coordonnées aux vulnérabilités, Canonical recommande que les problèmes sous embargo soient traités discrètement. Si des désaccords surviennent lors de la divulgation, des coordinateurs tiers, tels que le VINCE d’un CERT/CC, peuvent intervenir pour arbitrer la discussion.
Référenceshttps://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/
https://github.com/OpenPrinting/libcupsfilters/security/advisories/GHSA-w63j-6g73-wmg5
https://github.com/OpenPrinting/libppd/security/advisories/GHSA-7xfx-47qg-grp6
https://github.com/OpenPrinting/cups-browsed/security/advisories/GHSA-rj88-6mr5-rcw8
https://github.com/OpenPrinting/cups-filters/security/advisories/GHSA-p9rh-jxmq-gq47
https://ubuntu.com/security/CVE-2024-47076
https://ubuntu.com/security/CVE-2024-47175
https://ubuntu.com/security/CVE-2024-47176
https://ubuntu.com/security/CVE-2024-47177
https://ubuntu.com/security/notices/USN-7041-1
https://ubuntu.com/security/notices/USN-7042-1
https://ubuntu.com/security/notices/USN-7043-1
https://ubuntu.com/security/notices/USN-7044-1
https://ubuntu.com/security/notices/USN-7045-1
https://www.cve.org/CVERecord?id=CVE-2024-47076
https://www.cve.org/CVERecord?id=CVE-2024-47175
https://www.cve.org/CVERecord?id=CVE-2024-47176
https://www.cve.org/CVERecord?id=CVE-2024-47177
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
S'inscrire Se connecter