Connexion
Abonnez-vous

Unix/Linux : importante faille dans Sudo, le correctif disponible

Unix/Linux : importante faille dans Sudo, le correctif disponible

Le 15 octobre 2019 à 09h03

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.

Abonnez-vous
votre avatar



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.

votre avatar

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

votre avatar







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 ;)


votre avatar

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

votre avatar

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 

 

 

votre avatar
votre avatar







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.


votre avatar

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 ?



 

votre avatar







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 ?


votre avatar

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

votre avatar







fabcool a écrit :



Bref c’est mort.





Bah non, c’est juste qu’en croisant les liens tu finis par avoir toutes les réponses ;)

 

Si tu veux les cloisonner sur leur dossier, tu DOIS utiliser chroot (sur une distri linux bien sûr).

Et en effet, le dossier qui emprisonne l’utilisateur doit être détenu par root:root.

Mais rien ne t’empêche de créer un sous-dossier (au pif… www ?) qui sera détenu par ton user.

et donc tout ce qu’il contiendra pourra être modifié par ton user.

 

Tu as donc un user dans son environnement chrooté, contenant un ou plusieurs dossiers dans lesquels il mettra ses données/sources, et tu peux même rajouter des fichiers de configuration dans sa racine en 644 lui permettant de les lire, mais seulement à root de les modifier (configurer sa version php par exemple, ou autre, comme le font certains hébergeurs).



Ma source :wiki.archlinux.org archlinux:

Write permissions

The bind path needs to be fully owned by root, however files and/or subdirectories don’t have to be.

In the following example the user www-demo uses /srv/ssh/www/demo as the jail-directory:



# mkdir /srv/ssh/www/demo/public_html

# chown www-demo:sftponly /srv/ssh/www/demo/public_html

# chmod 755 /srv/ssh/www/demo/public_html



The user should now be able to create files/subdirectories inside this directory. See File permissions and attributes for more information.


votre avatar

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.

votre avatar

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

votre avatar

ssh chroot jail + selinux + acl et tu obtiens un truc aux petits oignons

votre avatar

Toujours la version 1.8.27 sous Debian 10 (Buster) version serveur.

votre avatar







fabcool a écrit :



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.







/var/www/nomdupresta/ appartient à root

sitweb/ appartient à nomdupresta



chacun étant chrooté dans son /var/www/nomdupresta/


votre avatar

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 <img data-src=" />

votre avatar

/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/

votre avatar







fabcool a écrit :



Hey question !

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)





Jailkit fait bien le taf :

https://olivier.sessink.nl/jailkit/



Un tuto

https://www.howtoforge.com/debian-9-jail-jailkit/



Mise à jour appliquée ce matin sur mon VPS avec Debian 8 :)


votre avatar







fabcool a écrit :



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







Pourquoi prendre la peine de te répondre ?


votre avatar







guildem a écrit :



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







Si les prestas n’ont pas accès en lecture à /var/www/ mais seulement le droit de traverser (droits -r et +x) ils ne peuvent lister le contenu de ce répertoire.


votre avatar







Cumbalero a écrit :



Si les prestas n’ont pas accès en lecture à /var/www/ mais seulement le droit de traverser (droits -r et +x) ils ne peuvent lister le contenu de ce répertoire.







-r, c’est les droits de lecture. <img data-src=" />


votre avatar







Ricard a écrit :



-r, c’est les droits de lecture. <img data-src=" />







Non, c’est +r <img data-src=" />


votre avatar







Cumbalero a écrit :



Non, c’est +r <img data-src=" />





C’était ironique… <img data-src=" />


votre avatar

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.

votre avatar

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 : …



&nbsp;

votre avatar

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 <img data-src=" />

votre avatar

j’ai quand même fait un update de tous nos serveurs par acquis de conscience.

votre avatar

C’est plus une faille, c’est un gouffre !



D’où l’utilité de le combler (ok, je sors)

votre avatar

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.

Unix/Linux : importante faille dans Sudo, le correctif disponible

Fermer