¿Por qué checksec.sh resalta rpath y runpath como problemas de seguridad?

TL; DR: R*PATH tiene un historial desafortunado de introducir nuevas formas de ejecutando bibliotecas no confiables (controladas por el atacante). RPATH / RUNPATH suele ser evitable y debe evitarse.

En primer lugar, podría valer la pena revisar las razones no relacionadas con la seguridad por las que queremos estos binarios marcados: distros (por ejemplo, Debian Wiki en RPATH ) no me gusta que tenga prioridad sobre la local Configuración / configuración de LD_LIBRARY_PATH y /etc/ld.so.conf y convenciones Hace que sea más difícil razonar acerca de las bibliotecas a través de más medios visibles que ejecutar readelf para cada binario que queremos pensar acerca, y esto complica la vida para los mantenedores que hacen malabares mucho de dependencias entrelazadas a través de estos otros mecanismos que son Se rompe fácilmente por RPATH / RUNPATH . Pero hay excepciones - aquí está La política de Debian:

  

La única vez que una biblioteca binaria o compartida en un paquete Debian debe establecer RPATH o RUNPATH es si está vinculada a bibliotecas compartidas privadas en el mismo paquete.

En segundo lugar, RPATH relativo (es decir, foo.so en lugar de /usr/lib/foo.so ) puede ir bastante mal: su usuario puede estar ejecutando desde un directorio de trabajo (por ejemplo, /tmp ) que está sujeto al control del atacante ¿Quién podría plantar una versión maliciosa de /tmp/foo.so . Esta fue una observación hecha en error de Debian # 754278 contra openjdk .

Esto puede sonar benigno, pero puede llevar a privesc particularmente en setuid / setgid programas como DB2 privesc CVE-2014-0907 de IBM : simplemente ejecute el binario suid desde un directorio preparado para abusar de cualquier RPATH está establecido, y su código se ejecutará en el contexto de la Programa privilegiado. Otros ejemplos incluyen el paquete de Slackware de llvm CVE-2013-7171 , el paquete de Gentoo de Imagemagick CVE-2005-3582 , el paquete de SuSE de CVSup CVE-2004-2133 , ..). Ha sido un goteo tan constante que Avoids equivalente de Apple binarios restringidos "(suid / sgid).

En tercer lugar, la variable especial $ORIGIN (que llama a la ruta ejecutable) tiene Ha sido una forma de evitar un camino absoluto, mientras se ancla la búsqueda. en alguna parte . Pero ha tenido problemas: glibc CVE-2011-0536 no pudo amplíelo apropiadamente, lo que dio a los atacantes un equivalente del caso RPATH relativo donde el autor de un ejecutable que usa $ORIGIN pensó que estaba obteniendo algo un poco más robusto.

Teniendo esto en cuenta, es probable que realmente desees que checksec.sh marque RPATH / RUNPATH - no siempre es malo, pero checksec.sh no lo hace tenga la imagen más grande disponible para hacer esa llamada para usted como el Los linters de distro pueden, por lo que necesitan revisión manual.

Addendum: Rompiendo los enlaces: Explotando el enlazador por Tim Brown se mencionó en las respuestas Para su conversación de Twitter, este es un gran artículo sobre la superficie de ataque, en general para los enlazadores de estilo POSIX y los lectores astutos deberían echarle un vistazo. Lo más pertinente que no está cubierto ya es esto:

  

Al menos en GNU / Linux, cuando DT_RPATH o DT_RUNPATH existe dentro de los encabezados ELF de un binario, estos serán respetados primero cuando se busquen bibliotecas compartidas. Además, la palabra clave $ORIGIN dentro de este encabezado se expande para ser la ruta del directorio donde se encuentra el objeto.   Se encuentra, mientras que ambos. y se respetan las especificaciones de directorio vacío, incluso para los binarios con el conjunto de bits setUID. Desde el punto de vista de los atacantes, los binarios setUID con DT_RPATH son particularmente buenos, ya que podemos hacer uso de enlaces duros para manipular el enlazador de tiempo de ejecución para que use un $ORIGIN   que podemos controlar.

... como se observa en otra parte del documento, la mayoría de los sistemas ignoran las variables de entorno proporcionadas por el usuario como LD_LIBRARY_PATH en binarios de setuid la mayor parte del tiempo, pero como se puede ver, un RPATH descuidado le da al atacante un regalo equivalente .

2do anexo: ContextIS tiene un gran redacción que cubre los ataques RPATH .