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.
Commentaires (30)
#1
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.
#2
ç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.
#3
#4
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
#5
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
#6
https://www.tecmint.com/restrict-ssh-user-to-directory-using-chrooted-jail/ ?
#7
#8
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 ?
#9
#10
Parce qu’il y a plus de chance d’avoir une reaction à cette problématique, vu que c’est assez lié…
#11
#12
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.
#13
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).
#14
ssh chroot jail + selinux + acl et tu obtiens un truc aux petits oignons
#15
Toujours la version 1.8.27 sous Debian 10 (Buster) version serveur.
#16
#17
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
#18
/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/
#19
#20
#21
#22
#23
#24
#25
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.
#26
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 : …
#27
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
" />
#28
j’ai quand même fait un update de tous nos serveurs par acquis de conscience.
#29
C’est plus une faille, c’est un gouffre !
D’où l’utilité de le combler (ok, je sors)
#30
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.