Journal Faille d'exécution de code à distance dans cups

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
23
27
sept.
2024

Avant de lire plus loin, s'il vous plait, lancez sudo systemctl disable --now cups-browsed.

Plusieurs failles de sécurité ont été publiées concernant le serveur d'impression Linux CUPS et des logiciels qui y sont liés. Combinées, elles permettent à un utilisateur distant de faire exécuter du code en tant que root lp lors d'une impression initiée par un utilisateur du système. [EDIT : retrait de la mention d'élévation de privilège vers root]

La plupart des systèmes Linux de bureau activent CUPS et cups-browsed par défaut. Certains serveurs sur internet exposent cups-browsed signale l'auteur.

L'auteur a tenté de suivre une procédure de responsible disclosure, ça ne s'est pas bien passé : alors que nous sommes encore théoriquement sous embargo, les failles sont déjà publiques avec des codes d'exploitation disponibles immédiatement (ou très faciles à reconstruire). Les correctifs ne sont pas encore publiés. À l'heure où j'écris ce journal, ni RedHat ni Debian n'ont publié de mise à jour de CUPS.

Il semble prudent, dans l'attente, de désactiver le service cups-browsed qui auto-installe des imprimantes réseau sans interaction avec l'utilisateur.

Références :

  • # désactivé par défaut

    Posté par  (Mastodon) . Évalué à 7 (+5/-1). Dernière modification le 27 septembre 2024 à 23:11.

    Avant de lire plus loin, s'il vous plait, lancez sudo systemctl disable --now cups-browsed
    La plupart des systèmes Linux de bureau activent CUPS et cups-browsed par défaut.

    Je crois que ce service n'est justement activé par défaut sur aucune distro digne de ce nom. Ça ne l'est en tout cas pas sur fedora / rhel / archlinux…

    • [^] # Re: désactivé par défaut

      Posté par  . Évalué à 1 (+1/-1).

      hello,

      je n'ai pas lu mais cups ça écoute pas sur 127.0.0.1 par défaut ?

      oau

      • [^] # Re: désactivé par défaut

        Posté par  . Évalué à 6 (+5/-0).

        Attention, cupsd écoute sur localhost, oui.
        Mais pas cups-browsed ! Et attention, c'est en UDP.

        Pour voir vraiment ce qui écoute sur ce port 631 :

        $ sudo lsof -i :631

        Sur ma Debian sid, j'avais bien un cups-browsed qui écoutait en UDP sur le port 631, sans restriction d'adresse ou d'interface.

        • [^] # Re: désactivé par défaut

          Posté par  . Évalué à 4 (+3/-0).

          Effectivement le fichier de configuration par défaut fourni par les mainteneurs Debian contient :
          BrowseRemoteProtocols dnssd cups
          Il suffit de remplacer par :
          BrowseRemoteProtocols dnssd
          et de relancer le service.

        • [^] # Re: désactivé par défaut

          Posté par  (Mastodon) . Évalué à 6 (+3/-0).

          Idem sur ma Debian qui me sert de bastion :(

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: désactivé par défaut

      Posté par  . Évalué à 1 (+2/-2).

      Je l'ai retrouvé activé par défaut sur des serveurs amis. Après est-ce que Ubuntu est un distro digne de ce nom ?

      • [^] # Re: désactivé par défaut

        Posté par  . Évalué à 3 (+1/-0).

        Disons que sur Ubuntu le fix est disponible. Moi qui suis passé sur le PC du boulot a Debian, j'avais plus le choix qu'entre Ubuntu et Debian pour pouvoir installer vanta, j'ai pris Debian pour être plus vanilla, ta remarque un poil condescendante me fait pas mal sourire tout de même.

        Bref c'est pas grave, le PC va rester éteint ce weekend.

    • [^] # Re: désactivé par défaut

      Posté par  . Évalué à 5 (+3/-0).

      Je crois que ce service n'est justement activé par défaut sur aucune distro digne de ce nom.

      Concernant Arch, cups-browsed n'est pas inclus dans Cups, c'est un paquet à part
      https://archlinux.org/packages/extra/x86_64/cups-browsed/

    • [^] # Re: désactivé par défaut

      Posté par  . Évalué à 5 (+3/-0).

      Il était actif par défaut sur ma Debian bookworm toute neuve…

      • [^] # Re: désactivé par défaut

        Posté par  . Évalué à 7 (+5/-0).

        Oui, sur les environnements de bureau comme Gnome ou KDE, ça va être une dépendance optionnelle.

        Un truc que j'aime bien faire est de demander à apt de ne pas installer de telles dépendances, avec APT::Install-Recommends "false"; dans la configuration d'apt. Ainsi, on a un système qui fonctionne, mais pas avec tout le confort, et on peut ajouter les options au fur et à mesure. Je trouve que c'est une meilleure approche que d'installer plus, puis de supprimer.

        Sur une Debian, ça reviendrait à :
        - ne pas installer la couche graphique pendant l'install
        - configurer apt pour ne pas installer les dépendances optionnelles
        - installer la "task" ou le méta-paquet qui correspond à ce que tu veux.

        Avec un fichier pre-seed on peut aussi faire :

        d-i base-installer/install-recommends boolean false

        Sur un serveur c'est génial, l'install devient assez petite :)

    • [^] # Re: désactivé par défaut

      Posté par  . Évalué à 3 (+1/-0).

      Jamais compris l'intérêt de ce truc

  • # cups-browsed pas cupsd

    Posté par  . Évalué à 3 (+2/-0). Dernière modification le 28 septembre 2024 à 00:03.

    Mince, comment on supprime un message ?

  • # Infos à vérifier

    Posté par  . Évalué à 6 (+5/-0).

    elles permettent à un utilisateur distant de faire exécuter du code en tant que root lors d'une impression initiée par un utilisateur du système. En particulier, elle permet donc à un utilisateur local de devenir root par ce biais.

    Je n'ai pas tout décortiqué mais je n'ai vu nulle part que cela permettait une élévation de privilège. Le code malveillant injecté est en principe exécuté par l'utilisateur système lp

    La plupart des systèmes Linux de bureau activent CUPS et cups-browsed par défaut. Certains serveurs sur internet exposent cups-browsed signale l'auteur.

    Certes mais les conditions de l'exploitation de la faille rendent son succès très improbable. Et de ce point de vue les valeurs de CVSS me semblent encore largement exagérées (il y a déjà eu débat sur la pertinence de ces indicateurs de gravité).

    cf. https://www.redhat.com/en/blog/red-hat-response-openprinting-cups-vulnerabilities
    (voir aussi la discussion dans la rubrique liens de linuxfr)

    L'auteur a tenté de suivre une procédure de responsible disclosure, ça ne s'est pas bien passé

    C'est probablement du fait de son ego surdimensionné d'une mauvaise communication et d'un manque de patience de sa part.

    • [^] # Re: Infos à vérifier

      Posté par  . Évalué à 5 (+6/-2).

      J'oubliais l'essentiel. Inutile de désactiver un service qui peut être utile.
      Cela se règle dans la configuration de cups-browsed, voir les directives BrowseProtocols dans man cups-browsed.conf.
      Et comme c'est essentiellemnt un problème de configuration par défaut (sur certaines distributions ?) on peut comprendre que certains développeur soient réticents pour corriger la faille au niveau du code.

      • [^] # Re: Infos à vérifier

        Posté par  . Évalué à 1 (+1/-0). Dernière modification le 28 septembre 2024 à 09:01.

        Bonjour,
        a priori la course aux update est lancée !!
        #
        # Patches available for packages affected by CUPS Remote Code Execution issue
        # tracked by CVE-2024-47076, CVE-2024-47175, CVE-2024-47176, and CVE-2024-47177
        # For more see: https://ubuntu.com/blog/cups-remote-code-execution
        #cups cups-browsed cups-bsd cups-client cups-common cups-core-drivers cups-daemon cups-filters
        cups-filters-core-drivers cups-ipp-utils cups-ppdc cups-server-common

        ce matin 28/09/24 ubuntu 20.04.

      • [^] # Re: Infos à vérifier

        Posté par  (site web personnel) . Évalué à 8 (+7/-0).

        J'oubliais l'essentiel. Inutile de désactiver un service qui peut être utile.

        J'adopte le principe inverse : inutile d'activer un service dont je ne suis pas certain de l'utilité (relativement à mes cas d'usage).

        Typiquement, dans ce cas : je n'ai qu'une imprimante, branchée en USB sur mon poste, je n'ai pas besoin de ce service. Autant le désactiver (quitte à le réactiver temporairement, un jour, si je pense que ça simplifiera la configuration d'une nouvelle imprimante réseau).

        Le soucis, c'est que la distribution doit prendre une décision pour tout le monde. L'arbitrage entre facilité d'utilisation ("l'utilisateur n'a rien à faire, tout va fonctionner") et position défensive ("rien n'est installé ni activé par défaut, l'utilisateur doit explicitement demander ce dont il a besoin") est très complexe.

        • [^] # Re: Infos à vérifier

          Posté par  . Évalué à 3 (+2/-0).

          J'oubliais l'essentiel. Inutile de désactiver un service qui peut être utile.

          Je reformule puisque cela n'était pas clair.

          Inutile de demander à tout le monde de désactiver un service qui peut être utile à certains.

          Il y a d'autres moyens de se protéger de cette faille, il suffit que le service ne soit plus en écoute en UDP sur le port 631, sans que cela ait de conséquences négatives pour certains utilisateurs (mais pourquoi mon imprimante réseau n'est plus reconnue automatiquement ?)

          Mais puisque tu réponds, as-tu bien vérifié que cette faille permet une élévation de privilège et une exécution de code arbitraire en tant que root ?

          • [^] # Re: Infos à vérifier

            Posté par  . Évalué à 4 (+2/-0).

            Cette faille permet une exécution de code dans le contexte du plugin "foomatic" de cups, et donc dans le contexte de cupsd.
            Sur mon Archlinux, c'est donc en tant que root. C'est peut-être "lp" chez toi.

            • [^] # Re: Infos à vérifier

              Posté par  . Évalué à 3 (+2/-0). Dernière modification le 29 septembre 2024 à 12:51.

              C'est à l'auteur de ce journal que je demande de faire cette vérification parce que je pense qu'il a commis une grosse erreur dans l'emballement de la découverte de ce problème.
              Si tu veux apporter ta contribution il faut fournir une argumentation étayée.

              Relis bien le texte et regarde bien la vidéo postée sur le site du découvreur de cette faille:
              le fichier malveillant injecté appartient à lp. Il a donc été créée par cet utilisateur et non par root.

              • [^] # Re: Infos à vérifier

                Posté par  (site web personnel) . Évalué à 5 (+4/-0).

                C'est à l'auteur de ce journal que je demande de faire cette vérification parce que je pense qu'il a commis une grosse erreur dans l'emballement de la découverte de ce problème.

                Tu as raison. J'avais simplement vérifié que cups tournait avec les droits root et j'en avais déduit, trop rapidement, que les commandes ainsi injectées s'exécutaient avec ces privilèges. Ce n'est pas ce que montre la vidéo postée par Simone, le fichier malveillant appartient à lp.

                Donc en l'état, ça permet une exécution de code en tant que lp, pas en tant que root. L'impact semble dès lors plus limité.

                Est-ce qu'un modérateur peut éditer le journal initial ? Je propose de remplacer le deuxième paragraphe par :

                Plusieurs failles de sécurité ont été publiées concernant le serveur d'impression Linux CUPS et des logiciels qui y sont liés. Combinées, elles permettent à un utilisateur distant de faire exécuter du code en tant que rootlp lors d'une impression initiée par un utilisateur du système. En particulier, elle permet donc à un utilisateur local de devenir root par ce biais. [EDIT : retrait de la mention d'élévation de privilège vers root].

                Pouvez-vous en même temps modifier le titre en : "Faille d'exécution de code à distance / élévation de privilège dans cups" ?

                Merci.

        • [^] # Re: Infos à vérifier

          Posté par  . Évalué à 6 (+4/-0).

          Le soucis, c'est que la distribution doit prendre une décision pour tout le monde. L'arbitrage entre facilité d'utilisation ("l'utilisateur n'a rien à faire, tout va fonctionner") et position défensive ("rien n'est installé ni activé par défaut, l'utilisateur doit explicitement demander ce dont il a besoin") est très complexe.

          J'aime bien le bluetooth pour ça. Tu dis: "ok pour 90s, vazy, écoute le monde entier".
          Et ensuite, c'est configuré et tu es content et ça marche. Et après, plus d'inquiétudes ni de questions à se poser genre "est-ce qu'une faille va permettre à un pirate de faire ci ou ça".

          Ca pourrait être une solution pour cups-browsd, on clique sur un bouton, pendant 2mn on est à risque, et après on est safe.

      • [^] # Re: Infos à vérifier

        Posté par  . Évalué à 6 (+5/-1).

        Et comme c'est essentiellemnt un problème de configuration par défaut

        Bah l'existence même de ce truc, c'est de dire: "on écoute sur le réseau au cas où une imprimante se signale".

        Après, oué, tu peux limiter ce serveur à localhost. Du coup… Bah tu n'es plus au courant que des imprimantes sur le réseau se signalent à toi?

        Donc bon, soit tu écoutes le réseau et le service est utile, soit tu écoutes pas le réseau et le service sert à rien du coup?

        • [^] # Re: Infos à vérifier

          Posté par  . Évalué à 1 (+6/-6).

          Bah l'existence même de ce truc, c'est de dire: "on écoute sur le réseau au cas où une imprimante se signale".

          On écoute sur le port 631 en UDP au cas ou un vieux serveur CUPS (≤1.5 sortie il y a 13 ans) veuille s'annoncer ainsi. Sinon le protocole Bonjour/mDNS est suffisant.

          Il suffit de lire la page de man, ce que chacun devrait faire avant de discuter des problèmes et de leurs éventuelles solutions ;-)

          • [^] # Re: Infos à vérifier

            Posté par  . Évalué à 4 (+2/-0).

            On écoute sur le port 631 en UDP au cas ou un vieux serveur CUPS (≤1.5 sortie il y a 13 ans) veuille s'annoncer ainsi.

            C'est exactement ce que je dis (?)

            Il suffit de lire la page de man, ce que chacun devrait faire avant de discuter des problèmes et de leurs éventuelles solutions ;-)

            je comprends pas trop la remarque.

  • # Est-ce qu'il y a moyen de tester si l'imprimante réseau est sujette à cette faille ?

    Posté par  . Évalué à 4 (+4/-1).

    Hello,
    J'ai une imprimante en wifi sur mon réseau.
    Est-ce qu'il y a moyen de tester si l'imprimante réseau est sujette à cette faille ?

  • # Liens supplémentaires

    Posté par  (site web personnel) . Évalué à 6 (+3/-0).

    Références CVE-2024-47076, CVE-2024-47175, CVE-2024-47176, CVE-2024-47177

  • # #apt update && apt upgrade

    Posté par  . Évalué à 1 (+0/-0).

    Mise à jour disponible pour Debian/stable “bookworm” :

    « Les paquets suivants seront mis à jour :
    cups cups-browsed cups-bsd cups-client cups-common cups-core-drivers cups-daemon cups-filters cups-filters-core-drivers cups-ipp-utils cups-ppdc cups-server-common libcups2 libcupsfilters1 libcupsimage2 libfontembed1 »

  • # et pour les produits Apple ?

    Posté par  . Évalué à 1 (+2/-1).

    Bonjour à tous, petite question, d'effet de bord dirons nous, cups étant utilisé (pour ne pas dire plus) par Apple, est ce que vous savez si l'équivalent de "cups-browsed" pour macos existe et est concerné ?
    Pour l'instant je n'ai rien trouvé.
    J'imagine que parmi les administrateurs linux qui consultent le site, il y en a qui travaillent en environnement hétérogène.

Envoyer un commentaire

Suivre le flux des commentaires

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