Skip to main content

Faille RCE zero-day découverte dans CUPS - Common UNIX Printing System

Écrit par
feature insights context

27 septembre 2024

0 minutes de lecture

Le 27 septembre 2024, evilsocket.net (Simone Margaritelli) a publié des informations sur plusieurs vulnérabilités de CUPS (Common UNIX Printing System), susceptibles de permettre l’exécution de code arbitraire à distance (RCE). Quatre CVE sont actuellement associées à ces découvertes, et d’autres pourraient suivre. La gravité de ces vulnérabilités fait également débat ; toutefois, l’une des CVE s’est initialement vu attribuer un score CVSS de 9,9. Nous mettrons cet article à jour si de nouvelles informations sont disponibles.

Remarque importante : d’autres CVE pourraient être publiées concernant ces vulnérabilités et d’autres découvertes par Simone, le chercheur à l’origine de leur signalement. Nous mettrons cet article à jour avec de nouvelles informations si nécessaire.

Ce que nous savons à ce jour

Une nouvelle vulnérabilité zero-day touchant Common UNIX Printing System (CUPS), un package populaire de prise en charge des imprimantes, a été découverte. Elle affecte les packages en aval cups-browsed, libcupsfilters, cups-filters et libppd. Ces vulnérabilités permettent l’exécution de code à distance (RCE) sans authentification, et au moins l’une d’elles s’est vu attribuer un score CVSS de 9,9. Toutefois, l’exploitabilité de la faille est limitée aux serveurs sur lesquels le service CUPS est activé. Elle nécessite soit un accès au port UDP 631 (notez qu’il est possible de configurer CUPS sur un autre port), plus courant depuis un réseau externe, soit l’accès à DNS-SD, plus courant sur les réseaux internes.

Plusieurs avis de sécurité concernent cette vulnérabilité :

La faille affecte actuellement toutes les versions antérieures des packages suivants :

  • distrotech/cups-filters - toutes les versions

  • OpenPrinting/cups-filters - toutes les versions

  • cups-browsed - toutes les versions

  • libcupsfilters - toutes les versions

  • libppd - toutes les versions

CUPS fait partie des systèmes d’exploitation UNIX et Linux depuis 1999. Il est largement distribué avec de nombreuses distributions UNIX et Linux, ainsi qu’avec Apple, Windows et d’autres systèmes d’exploitation. CUPS fournit des services d’impression et écoute donc généralement les requêtes réseau, ce qui l’expose aux vulnérabilités et aux attaques RCE.

Comment vous préparer à la remédiation

Snyk détecte ces vulnérabilités avec Snyk Open Source et Snyk Container, notamment dans les packages C/C++ non gérés. De plus, Snyk et nos partenaires de sécurité à l’exécution peuvent vous indiquer si des conteneurs vulnérables sont en cours d’exécution et, dans de nombreux cas, déterminer si les processus CUPS concernés sont chargés dans le conteneur pendant son exécution et si celui-ci est configuré pour accéder au réseau.

  • Vérifiez l’utilisation de vos conteneurs et packages afin d’évaluer votre exposition à CUPS.

  • Déterminez si vous avez réellement besoin de CUPS et envisagez de le supprimer ou de le désactiver si ce n’est pas le cas.

  • Si vous êtes certain que CUPS n’est pas nécessaire, envisagez de bloquer l’accès au port UDP 631 depuis les réseaux externes. Vous pouvez également envisager de bloquer le trafic DNS-SD sur les réseaux internes, mais sachez que DNS-SD est utilisé à d’autres fins que CUPS : des vérifications supplémentaires peuvent donc être nécessaires.

Snyk Open Source 

Pour détecter les packages concernés avec Snyk Open Source, utilisez la commande snyk test. Si vous avez du code et des bibliothèques C/C++, utilisez la commande snyk test --unmanaged. Les projets déjà analysés et surveillés par Snyk Open Source seront automatiquement testés à nouveau. Vous pouvez consulter ces projets.

L’importation de votre projet dans Snyk via nos intégrations SCM prises en charge (GitHub, Bitbucket, GitLab, Azure Repos) déclenche automatiquement un test. Vous pourrez ensuite utiliser l’interface Snyk pour identifier, hiérarchiser et corriger ces vulnérabilités dans vos projets. 

  • Snyk CLI et intégrations CI/CD :

    • snyk test pour la plupart des langages

    • snyk test --unmanaged pour les projets C/C++

    • Vous pouvez également utiliser snyk monitor pour assurer une surveillance continue de ces projets.

  • Gestionnaires de code source :

    • Détection automatique lors des nouvelles importations

    • La nouvelle analyse automatique des projets existants est en cours

    • Par défaut, les projets existants sont mis à jour quotidiennement de façon automatique

  • IDE :

    • Les plugins IDE de Snyk s’appuient sur Snyk CLI et détectent ces vulnérabilités lors d’une analyse.

Snyk Container

Pour détecter les images de conteneur concernées avec Snyk Container, utilisez la commande snyk container test. Si vous avez déjà des projets analysés et surveillés par Snyk Container, ils seront automatiquement testés à nouveau. Vous pouvez les consulter dès maintenant.

Snyk CLI et intégrations CI/CD :

  • snyk container test vérifie l’image du conteneur et recherche les manifestes de langages (par exemple, package.json) afin d’en détecter l’utilisation.

  • snyk container monitor analyse et détecte également les vulnérabilités, et assure une surveillance continue pour repérer celles à venir.

  • Registres de conteneurs :

    • Les conteneurs analysés via les intégrations de registres sont automatiquement vérifiés à la recherche de ces vulnérabilités lors de leur importation.

    • Les projets de conteneurs déjà importés signaleront la présence de cette vulnérabilité.

  • Gestionnaires de code source :

    • Snyk Container analyse les Dockerfiles lors des importations SCM, mais ne vérifie que l’image parente (la commande FROM) et ne signale les vulnérabilités que pour certaines images parentes certifiées Docker. Si l’image parente est prise en charge et présente cette vulnérabilité, celle-ci sera signalée. Toutefois, l’analyse des images de conteneur réelles après leur création reste la méthode de détection la plus fiable.

Priorisation à l’aide du Risk Score de Snyk

Vous allez probablement trouver plusieurs problèmes liés à cups dans vos projets, ce qui peut compliquer le choix des correctifs à appliquer en priorité. Le score de risque des problèmes de Snyk prend en compte de nombreux facteurs pour vous aider à repérer rapidement ceux à traiter en premier. Il inclut différents signaux, tels que l’EPSS, le niveau de maturité de l’exploit, le CVSS et les tendances sur les réseaux sociaux. Vous pouvez ainsi parcourir rapidement la liste des vulnérabilités et prioriser les correctifs en conséquence. 

Le score s’affiche pour chaque problème détecté sur la page Projects et figure également dans les rapports Snyk.

Tableau de bord des risques de vulnérabilité pour cups/libcups2 : validation incorrecte des entrées, score de risque de 64 et probabilité de 2,7.

Snyk Reports

Un nouveau rapport consacré à cet ensemble de vulnérabilités est disponible dans la liste « Featured Zero-Day » de Snyk. Si vous disposez d’un abonnement Enterprise, vous pouvez accéder à ce rapport en cliquant sur « Reports » dans le menu de navigation de gauche (des rapports sont disponibles aux niveaux du groupe et de l’organisation). Par défaut, le rapport « Issues Detail » s’affiche. Cliquez sur le menu déroulant « Change Report » à côté du titre du rapport, puis sélectionnez « Featured Zero-Day ». Sur l’écran suivant, sélectionnez le rapport CUPS dans la liste déroulante Zero-Day.

Tableau de bord des détails des problèmes Snyk filtré sur CVE-2024-47175, affichant cinq problèmes de gravité moyenne dans plusieurs projets.

Vous pouvez également utiliser les CVE avec d’autres filtres des rapports Issues Detail, Issues Summary, Vulnerabilities Detail et SLA Management pour créer, enregistrer et partager vos propres rapports personnalisés afin de suivre cette vulnérabilité dans toutes les détections Snyk Open Source et/ou Snyk Container. Filtrez les rapports et autres pages par CVE : CVE-2024-47177, CVE-2024-47176, CVE-2024-47076 et CVE-2024-47175. 

La vidéo ci-dessous montre comment filtrer une CVE, mais vous pouvez en ajouter autant que vous le souhaitez à la fois :

Tableau de bord Snyk affichant une liste des projets les plus vulnérables, avec le nombre de problèmes par niveau de gravité et un bouton Corriger les vulnérabilités

Filtrage du tableau de bord

L’entonnoir Insights de l’écran Issues identifie les instances actives des applications présentant ces vulnérabilités et disposant également d’un accès au réseau externe. Là encore, vous pouvez ajouter un filtre pour vous concentrer uniquement sur ces problèmes.

Tableau de bord des problèmes Snyk affichant 27 566 problèmes ouverts, classés par priorité selon les facteurs de risque, avec des filtres par statut, gravité, actifs et projets.

Que fait Snyk ?

Les experts en sécurité de Snyk suivent activement les mises à jour de versions, les informations sur les vulnérabilités, les échanges sur les réseaux sociaux et bien plus encore afin de transmettre à nos clients toute nouvelle information. En outre, des recherches sont en cours pour identifier d’autres packages en aval susceptibles d’être concernés. Nous mettrons cet article à jour si nécessaire. Si vous avez des questions sur ces vulnérabilités, n’hésitez pas à nous contacter via le Discord de la communauté Snyk ou à vous inscrire pour bénéficier d’un essai gratuit et vérifier si vous êtes concerné par ces vulnérabilités.

Démarrez gratuitement avec Snyk

Aucune carte bancaire requise.

Créer un compte avec Bitbucket et découvrir d’autres options

En utilisant Snyk, vous acceptez de respecter nos politiques, notamment nos Conditions d’utilisation et notre Politique de confidentialité.

Lire la suite

feature insights context
Blog

Les attaques autonomes sont déjà là. La défense doit suivre leur rythme.

Les attaquants autonomes réduisent la fenêtre de défense. Découvrez comment la découverte, la correction, la validation et la prévention continues peuvent aider les équipes de sécurité à suivre le rythme.

feature insights context
Blog

La prévention est-elle essentiellement un problème résolu ?

La prévention dans le code généré par les agents est résolue sur le plan architectural, mais le défi reste de choisir des contrôles qui protègent la sécurité sans ralentir le développement.

Live Stream

Les agents de remédiation démystifiés : pourquoi corriger vaut mieux que détecter

Découvrez comment l’agent de remédiation de Snyk utilise les renseignements de sécurité, l’analyse de la cassabilité et la validation pour transformer les vulnérabilités en pull requests prêtes à être fusionnées.