Unix/Linux : importante faille dans Sudo, le correctif disponible
Le 15 octobre 2019 à 09h03
2 min
Logiciel
Logiciel
Sudo est probablement l’un des utilitaires les plus utilisés et connus du monde Unix/Linux. Il sert à donner temporairement des droits plus élevés à un processus, sans avoir à basculer l’ensemble du compte utilisateur sur des droits équivalents.
La vulnérabilité, estampillée CVE-2019-14287, permet à un programme malveillant ou un utilisateur de contourner les règles de sécurité de Sudo pour exécuter un code arbitraire. Les privilèges peuvent même être obtenus quand la configuration de l’outil interdit explicitement l’accès root.
Cette faille particulière prend appui sur la conception de Sudo, qui permet en théorie à n’importe quel utilisateur avec des droits suffisants d’exécuter une commande en tant qu’un autre compte. Cette transversalité peut ainsi remonter jusqu’aux privilèges root.
Pour l’exploiter, un programme ou un utilisateur malveillant doit utiliser l’ID « - 1 » ou « 4294967295 ». Pourquoi ces identifiants ? Parce que la fonction chargée de convertir l’ID en nom d’utilisateur traite ces deux valeurs comme « 0 », qui correspond à root.
Il y a tout de même une condition : au moins un utilisateur doit avoir été déclaré dans le fichier de configuration situé dans /etc/sudoers. Les développeurs de Sudo donnent l’exemple suivant :
myhost bob =(ALL, !root) /usr/bin/vi
Cette ligne déclare que « bob » peut exécuter vi en tant que n’importe quel autre utilisateur, excepté root. À cause de la faille toutefois, bob pourra exécuter vi en tant que root s’il exécute d’abord la commande sudo -u#- 1 vi
.
La brèche a été colmatée dans la version 1.8.28 de Sudo publiée hier soir. La mise à jour est déployée progressivement sur l’ensemble des système concernés (et ils sont nombreux). La faille n’est pas critique, mais est considérée comme importante. Il est donc recommandé d’installer la nouvelle version dès que possible.
Le 15 octobre 2019 à 09h03
Commentaires (30)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 15/10/2019 à 08h21
Il y a tout de même une condition : au moins un utilisateur doit avoir été déclaré dans le fichier de configuration situé dans /etc/sudoers. Les développeurs de Sudo donnent l’exemple suivant :
D’après ce que j’ai lu, ce n’est pas le fait d’avoir un utilisateur en sudoer qui pose problème. C’est d’avoir tous sauf root en permission (la règle ALL, !root) le soucis. Et c’est une règle qui n’est pour ainsi dire jamais utilisée dans les configurations.
Le 15/10/2019 à 08h25
ça reste très particulier comme faille. sudo est généralement utilisé pour donner des accès root justement, mais ça reste une bonne idée de la combler ceci dit.
Le 15/10/2019 à 08h31
Le 15/10/2019 à 08h34
Je comprends pareil
“ Les privilèges peuvent même être obtenus quand la configuration de l’outil interdit explicitement l’accès root.”
le “même” est en trop et change l’interprétation de la news
Le 15/10/2019 à 09h09
Hey question !
comment faites vous pour vos presta web pour les enfermer dans leurs répertoires par site web par exemple ?
genre /var/www/site1 /var/www/site2 etc
Sachant que:
accès SSH (pas vsftp & cie)
il doivent pouvoir exécuter des script, y déposer des fichiers, les modifier (moulinettes symfony, et cie)
et ils ne doivent pas être www-data (car on donne pas d’écriture à www-data)
Si je les fous en sudoers il peuvent aller partout :/
Sous windows c’est facile en mettant en place des Resctricted Group,
mais sous debian malgré la profusion de HOWTO & cie je tourne en rond…
Et je ne parle pas de la tentative foireuse de combo avec un AD windows winbind & les ACL qu’on a eu au point de faire un roll back
Le 15/10/2019 à 09h28
https://www.tecmint.com/restrict-ssh-user-to-directory-using-chrooted-jail/ ?
Le 15/10/2019 à 09h35
Le 15/10/2019 à 09h46
Pourquoi répondre par des liens qu’on trouve en 2 min ?
Surtout quand on lit ça “Note that the chroot jail and its subdirectories and subfiles must be owned by root user, and not writable by any normal user or group”
Bref c’est mort.
Voilà pour le SSH chrooting, donc ?
Le 15/10/2019 à 09h52
Le 15/10/2019 à 09h53
Parce qu’il y a plus de chance d’avoir une reaction à cette problématique, vu que c’est assez lié…
Le 15/10/2019 à 09h58
Le 15/10/2019 à 10h15
Ah merci bien, je vais regarder ça, mais je suis pas fan à l’idée de faire genre /var/www/nomdupresta/siteweb car du coup les autres prestataires peuvent voir le nom des autres prestataires, je vais essayer d’organiser ce bordel
merci bien.
Le 15/10/2019 à 10h22
Bah si chacun est restreint à son /var/www/nomdupresta, il ne pourra pas voir les autres dossiers en théorie (à vérifier, mais il me semble que c’est correct).
Le 15/10/2019 à 10h30
ssh chroot jail + selinux + acl et tu obtiens un truc aux petits oignons
Le 15/10/2019 à 11h42
Toujours la version 1.8.27 sous Debian 10 (Buster) version serveur.
Le 15/10/2019 à 12h25
Le 15/10/2019 à 12h54
passé de 1.8.22-lp151.4.31 à 1.8.22-lp151.5.3.1 sous openSUSE :
downr@arsenic:~> sudo -u#-1 visudo
sudo: unknown user: #-1
sudo: unable to initialize policy plugin
marche plus " />
Le 15/10/2019 à 16h15
/home/nom-du-presta/
après, avec proftpd ou autre il me semble, mettre le répertoire / pour l’utilisateur dans le dossier /home/nom-du-presta/
Le 15/10/2019 à 16h26
Le 15/10/2019 à 17h58
Le 15/10/2019 à 18h02
Le 15/10/2019 à 18h05
Le 15/10/2019 à 18h15
Le 15/10/2019 à 18h29
Le 15/10/2019 à 19h29
Ce qui est dit un peu partout, c’est que cette faille permet à n’importe quel utilisateur linux de passer root. Exemple, le Monde Informatique :
“Une faille dans sudo ouvre un accès root aux utilisateurs Linux”
https://www.lemondeinformatique.fr/actualites/lire-une-faille-dans-sudo-ouvre-un…
Et en fait, on apprend que c’est faux et qu’il faut d’abord que le fichier sudoers ait été modifié pour permettre à l’utilisateur en question d’exécuter n’importe quelle commande au nom de n’importe quel utilisateur sauf root. Ce qui est une configuration très particulière et exceptionnelle. Donc encore une faille qui a été montée en épingle alors qu’elle n’est que très peu souvent exploitable. Et de plus c’est un exploit local, qui demande d’avoir déjà accès au système. Si un attaquant a déjà accès au système, c’est déjà très compromis pour la sécurité du système, même sans cette faille.
Perso, je vais attendre très tranquillement que les distribs mettent à jour cette faille, et pas me précipiter à installer de source sudo (configure, make, make install), comme je l’ai lu.
Le 15/10/2019 à 22h05
c’est tout à fait ça.
au taff notre pseudo dba qui nous sort,“hey vous avez patcher sudo ya une mega faille qui permet de passer root”
réponse : non les conditions sont très particulière et nous n’avons pas ce cas dans notre infra
réponse de la dba : “mais si jte lit je l’ai lu sur 01net”
réponse : …
Le 16/10/2019 à 05h56
tu kui demande de faire une circulaire au cas ou cela pete votre infra et que tu doit venir le week end pour tout regler " />
Le 16/10/2019 à 07h22
j’ai quand même fait un update de tous nos serveurs par acquis de conscience.
Le 16/10/2019 à 17h47
C’est plus une faille, c’est un gouffre !
D’où l’utilité de le combler (ok, je sors)
Le 19/10/2019 à 08h39
La commande est déjà à jour sur Fedora 30 pour info.
Par contre le package ne semble pas encore dispo sur RHEL et CentOS, sur une VM en CentOS 8 j’ai la version 1.8.25p1.