¿Es "LD_LIBRARY_PATH" un riesgo de seguridad?

Sabemos ld.sobúsquedas de bibliotecas en directorios especificados por la variable de entorno $LD_LIBRARY_PATH, pero los usuarios habituales podrían ejecutar:

export LD_LIBRARY_PATH=dir1:dir2...

Pueden guardar la biblioteca infectada en una ruta con mayor prioridad que la original para que ld.soencuentre esa en lugar de la biblioteca de confianza en el ld.so.cache.

¿Es esto un riesgo?
¿Cómo podemos deshabilitar la escritura en esta variable de entorno para el usuario normal?

Esto no es un riesgo de seguridad en absoluto, porque siempre puede establecer variables de entorno para su entorno actual (por ejemplo, sesión de Bash actual) y, utilizando el exportcomando, sus entornos secundarios (secuencias de comandos que inicia, subcapas, etc.). Es imposible escalar una variable de entorno creada o modificada en el entorno principal. Esto incluye que, por supuesto, es imposible que los usuarios habituales realicen cambios en todo el sistema.

Por lo tanto, el único entorno que se vería afectado si ejecuta export LD_LIBRARY_PATH=...es su shell actual y sus subcapas que podría generar más tarde. Supongamos que cambia la ruta de búsqueda para incluir bibliotecas infectadas al principio, es decir, con la máxima prioridad. Luego ejecuta un ejecutable que carga una de las bibliotecas infectadas sin siquiera saberlo. ¿Que pasa ahora?

Tiene un código malicioso (de la biblioteca infectada) que se ejecuta bajo su propia cuenta de usuario con privilegios regulares que no son de administrador. Esto puede sonar mal, pero en realidad ... ¿y qué? Se ejecuta con privilegios de usuario regulares, lo que nuevamente significa que no puede afectar a todo el sistema. Por cierto, ejecutar directamente un ejecutable con el mismo código malicioso habría sido mucho más fácil que modificar la ruta de búsqueda de la biblioteca y esperar a que un ejecutable normal lo cargue.

Conclusión: Un usuario normal solo puede modificar su propia ruta de búsqueda de la biblioteca, lo que significa que solo puede cargar esas bibliotecas bajo su cuenta de usuario normal con privilegios regulares que no son para todo el sistema. Dicho esto, no importa si fuerzan la carga de una biblioteca infectada o si ejecutan directamente un ejecutable infectado. No ganaría absolutamente nada si los usuarios no pudieran anular esa variable de entorno.

PD: También hay ejecutables que tienen establecido el setuid o setgid , lo que significa que no se ejecutarán como el usuario / grupo del que los ejecuta, sino del que los posee . Por ejemplo, el sudoejecutable es propiedad de root y tiene establecido el indicador setuid , lo que significa que siempre se ejecuta como root cuando se ejecuta. Por razones de seguridad, los $LD_LIBRARY_PATHejecutables ignoran la variable con uno de los indicadores setuid / setgid establecidos para asegurarse de que el usuario normal no pueda hacer que un ejecutable se ejecute con privilegios de root para cargar bibliotecas arbitrarias.
_{(¡Gracias a @Rinzwind por señalar esto!)}