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

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?

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é!)}