«LD_LIBRARY_PATH» est-il un risque pour la sécurité?


8

Nous connaissons les ld.sorecherches de bibliothèques dans les répertoires spécifiés par la variable d'environnement $LD_LIBRARY_PATH, mais les utilisateurs réguliers peuvent exécuter:

export LD_LIBRARY_PATH=dir1:dir2...

Ils peuvent enregistrer la bibliothèque infectée dans un chemin avec une priorité plus élevée que celle d'origine afin que ld.socelle-ci la trouve à la place de la bibliothèque approuvée dans le ld.so.cache.

Est-ce un risque?
Comment désactiver l'écriture dans cette variable d'environnement pour un utilisateur régulier?


Merci @Byte Commander pour l'édition. mon anglais n'est pas bon :)
Sinoosh

Pas de problème, c'est mieux que la moyenne :)
Byte Commander

Réponses:


17

Ce n'est pas du tout un risque pour la sécurité, car vous ne pouvez toujours définir que des variables d'environnement pour votre environnement actuel (par exemple la session Bash en cours) et, à l'aide de la exportcommande, ses environnements enfants (scripts que vous lancez, sous-coquilles, etc.). Il est impossible d'escalader une variable d'environnement créée ou modifiée dans l'environnement parent. Cela inclut qu'il est impossible pour les utilisateurs réguliers d'apporter des modifications à l'échelle du système, bien sûr.

Ainsi, le seul environnement qui serait affecté si vous exécutez export LD_LIBRARY_PATH=...est votre shell actuel et ses sous-coquilles que vous pourriez générer plus tard. Supposons que vous modifiez le chemin de recherche pour inclure les bibliothèques infectées au début, c'est-à-dire avec la priorité la plus élevée. Ensuite, vous exécutez un exécutable qui charge l'une des bibliothèques infectées sans même le savoir. Que se passe-t-il maintenant?

Vous disposez d'un code malveillant (provenant de la bibliothèque infectée) exécuté sous votre propre compte d'utilisateur avec des privilèges non administrateur réguliers. Cela peut sembler mauvais, mais en fait ... alors quoi? Il fonctionne avec des privilèges utilisateur réguliers, ce qui signifie qu'il ne peut pas affecter l'ensemble du système. Soit dit en passant, exécuter directement un exécutable avec le même code malveillant aurait été beaucoup plus facile que de modifier le chemin de recherche de la bibliothèque et d'attendre qu'un exécutable normal le charge.

Conclusion: Un utilisateur ordinaire ne peut modifier que son propre chemin de recherche de bibliothèque, ce qui signifie qu'il ne peut également charger ces bibliothèques elles-mêmes que sous son compte d'utilisateur normal avec des privilèges réguliers non étendus au système. Cela dit, cela ne fait aucune différence de forcer le chargement d'une bibliothèque infectée ou d'exécuter directement un exécutable infecté. Vous ne gagneriez absolument rien si cette variable d'environnement ne pouvait pas être remplacée par les utilisateurs.

PS: Il y a aussi des exécutables qui ont le drapeau setuid ou setgid , ce qui signifie qu'ils ne fonctionneront pas en tant qu'utilisateur / groupe de celui qui les exécute, mais de celui qui les possède . Par exemple, l' sudoexécutable appartient à root et possède l' indicateur setuid , ce qui signifie qu'il s'exécute toujours en tant que root lorsqu'il est exécuté. Pour des raisons de sécurité, la $LD_LIBRARY_PATHvariable est ignorée par les exécutables avec l'un des indicateurs setuid / setgid définis pour s'assurer que l'utilisateur normal ne peut pas exécuter un exécutable avec les privilèges root pour charger des bibliothèques arbitraires.
(Merci à @Rinzwind de l'avoir signalé!)


Merci beaucoup ! Je lis un livre qui dit que "le LD_LIBRARY_PATH est considéré comme un risque pour la sécurité car il peut autoriser l'accès accidentel de programmes non autorisés aux bibliothèques système ou exposer autrement les chemins d'accès aux bibliothèques système à des utilisateurs non autorisés". Quels moyens?
Sinoosh

1
@Sinoosh Je ne peux pas vraiment penser à une raison pour laquelle cela devrait être un problème de sécurité si une application non fiable connaît l'emplacement de mes bibliothèques système. Si tout est configuré correctement et que vous n'avez pas gâché les autorisations, elles doivent appartenir à root et ne peuvent être écrites par personne d'autre, ce qui signifie qu'il n'y a aucun risque qu'elles soient infectées ou modifiées de quelque manière que ce soit (sauf si vous exécutez l'application non approuvée en tant que root) , mais vous ne le ferez pas, non?)
Byte Commander


@ Byte Commander, je suis d'accord avec toi pas avec l'auteur :)
Sinoosh

Cette réponse n'est pas entièrement correcte. LD_LIBRARY_PATHest bien sûr un problème de sécurité lorsque vous chargez une bibliothèque malveillante en premier lieu et changez le comportement d'un binaire.
heemayl
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.