Journal Faille dans sudo

Posté par (page perso) . Licence CC by-sa.
Tags :
23
14
oct.
2019

Cher journal,

Je ne t’écris pas aujourd’hui pour te parler de bière, mais pour te parler d’une faille dans sudo. A priori, elle est assez grave, puisqu’elle permet à un utilisateur qui ne peut pas lancer de commande en tant que root à outrepasser cette restriction en passant le userid −1 ou 4 294 967 295. Ceci veut dire que la commande suivante:

sudo -u#-1 id -u

Renvoie 0. Cependant, cela arrive pour des cas de configuration spécifique. Il faut que la liste des utilisateurs pour lesquels on peut se faire passer avec la commande contienne ALL mais exclu root (ce qui est un cas assez spécifique, personnellement, je ne l’ai jamais vu dans une configuration sudo. Par exemple, la configuration suivante est vulnérable:

myhost bob = (ALL, !root) /usr/bin/vi

Dans le doute, il vaut mieux mettre à jour ses paquets ☺

Si vous avez une configuration du genre avec ALL mais qui exclu root, je serais curieux de savoir pourquoi.

L'explication du bug chez sudo: https://www.sudo.ws/alerts/minus_1_uid.html

  • # Découverte

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

    Je serais intéressé par savoir comment la faille a été découverte.

    Est-ce que c'est lors d'un audit ? De la lecture d'un code à modifier et un moment du style "eh mais attends…" ?

    • [^] # Re: Découverte

      Posté par (page perso) . Évalué à 7 (+4/-0).

      Elle a été découverte par un employé de la section "Sécurité" chez Apple. Je n'ai pas trouvé plus d'information.

      « 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

  • # all et groupes

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

    Est-ce vraiment une faille? Je lis Exploiting the bug requires that the user have sudo privileges that allow them to run commands with an arbitrary user ID.. Dans ce cas -1 (root) est donc inclus parmi les IDs, c'est assez logique.

    Si on veut donner accès en sudo à beaucoup d'utilisateurs humains mais pas à root, on fera plutôt des groupes d'utilisateurs. Cela évitera aussi de donner un sudo aux utilisateurs systèmes.

    • [^] # Re: all et groupes

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

      Dans ce cas -1 (root) est donc inclus parmi les IDs, c'est assez logique.

      C'est ce que je mets dans le journal, tu peux avoir ALL tout en excluant root.

      Si on veut donner accès en sudo à beaucoup d'utilisateurs humains

      Pourquoi distinguer les humains dans ce cas ?

      « 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: all et groupes

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

        Mon idée c'était juste que parfois tu veux donner accès à une commande à un groupe d'humains (genre lancer tuxracer) mais tu préfères limiter ça et ne pas étendre la commande à n'importe quel programme système (c'est prendre des risques inutiles, autant donner des permissions à juste ceux qui en ont besoin).

    • [^] # Re: all et groupes

      Posté par . Évalué à 4 (+2/-0). Dernière modification le 15/10/19 à 08:18.

      Cette faille n'est exploitable qu'avec une règle (ALL, !root).

      Personnellement je n'ai jamais vu ce genre de règles en général soit tu autorise un utilisateur à utiliser root, soit tu es hyper spécifique en définissant les comptes exacts dans lesquels tes users peuvent se "travestir"

      Donc c'est probablement une faille qui pourra peu être exploitée, raison probable pour laquelle il n'y a à priori pas eu d'embargo.

  • # Syntaxe sudoers fausse

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

    La syntaxe de configuration sudoers (fichier de conf /etc/sudoers ou sous /etc/sudoers.d) est fausse comme sur bon nombre d'articles.
    Celle indiquée sur le site officielle est bonne ! Surement un souci de copier/coller…
    Voilà la bonne syntaxe pour ceux qui souhaitent tester :
    toto test76 = (ALL, !root) /usr/bin/vi
    (user) (machine) et non pas l'inverse.

Envoyer un commentaire

Suivre le flux des commentaires

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