Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !
Unix/Linux : importante faille dans Sudo, le correctif disponibleCrédits : fizkes/iStock

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.

30 commentaires
Avatar de Cashiderme INpactien
Avatar de CashidermeCashiderme- 15/10/19 à 08:21:59

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.

Édité par Cashiderme le 15/10/2019 à 08:22
Avatar de Minikea INpactien
Avatar de MinikeaMinikea- 15/10/19 à 08:25:28

ç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.

Avatar de ultrariri INpactien
Avatar de ultraririultrariri- 15/10/19 à 08:31:39

Cashiderme a écrit :

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.

Que ce soit peu utilisé les pas le problème, ce qui est important c'est que ce soit possible. La solidité d'une chaîne dépends toujours du maillon le plus faible ;)

Avatar de azriek Abonné
Avatar de azriekazriek- 15/10/19 à 08:34:02

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

Édité par azriek le 15/10/2019 à 08:34
Avatar de fabcool Abonné
Avatar de fabcoolfabcool- 15/10/19 à 09:09:50

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 
 
 

Avatar de KP2 Abonné
Avatar de KP2KP2- 15/10/19 à 09:35:31

fabcool a écrit :

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

Renseigne toi sur le ssh chrooting... C'est un peu chiant a gérer mais ça marche.

Avatar de fabcool Abonné
Avatar de fabcoolfabcool- 15/10/19 à 09:46:06

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 ?

 

Avatar de Jarodd Abonné
Avatar de JaroddJarodd- 15/10/19 à 09:52:01

fabcool a écrit :

Pourquoi répondre par des liens qu'on trouve en 2 min ?

Pourquoi poser ce genre de question dans les commentaires d'un article, et pas dans un forum fait pour ça ?

Avatar de fabcool Abonné
Avatar de fabcoolfabcool- 15/10/19 à 09:53:21

Parce qu'il y a plus de chance d'avoir une reaction à cette problématique, vu que c'est assez lié...

Il n'est plus possible de commenter cette actualité.
Page 1 / 3