¿Es "LD_LIBRARY_PATH" un riesgo de seguridad?


8

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?


Gracias @Byte Commander por editar. mi inglés no es bueno :)
Sinoosh

No hay problema, es mejor que el promedio :)
Byte Commander

Respuestas:


17

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


Muchas gracias ! Estoy leyendo un libro que dice "LD_LIBRARY_PATH se considera un riesgo de seguridad porque podría permitir el acceso de programas no autorizados a las bibliotecas del sistema de forma accidental o exponer las rutas de la biblioteca del sistema a usuarios no autorizados". que significa
Sinoosh

1
@Sinoosh Realmente no puedo pensar en una razón por la que debería ser un problema de seguridad si una aplicación no confiable conoce la ubicación de las bibliotecas de mi sistema. Si todo está configurado correctamente y no ha alterado los permisos, deben ser propiedad de root y nadie más puede escribirlos, lo que significa que no hay riesgo de que se infecten o modifiquen de ninguna manera (a menos que ejecute la aplicación no confiable como root , pero no harás esto, ¿verdad?)
Byte Commander


@ Byte Commander, estoy de acuerdo con usted, no con el autor :)
Sinoosh

Esta respuesta no es del todo correcta. LD_LIBRARY_PATHes, por supuesto, un problema de seguridad cuando estás cargando una biblioteca maliciosa en primer lugar y cambias el comportamiento de un binario.
heemayl
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.