Procesos, /proc, PATH y variables de entorno

1Por qué importa

Cuando piensas en atacar un programa, imaginas un fallo en su código. Pero mucha de la escalada real en Linux no toca el código: toca lo que el programa hereda del entorno en que arranca. Un script de despliegue que llama a tar por su nombre confía en que el tar que se ejecute sea el del sistema. Esa confianza vive enteramente en el PATH, una variable heredada. Si alguien puede colocar un tar propio en un directorio que aparece antes en ese PATH, el script ejecutará su código, con la identidad del script, y nadie habrá explotado nada.

El otro lado de la moneda es lo que el proceso revela. El kernel mantiene un sistema de archivos virtual, /proc, con una carpeta por proceso. Ahí está su línea de comandos completa, su entorno completo y la lista de sus descriptores de archivo. Si el proceso recibió una contraseña como argumento o como variable de entorno, esa contraseña está en /proc, en texto plano, mientras el proceso viva. Entender qué filtra /proc es entender por qué "pasar el secreto por variable de entorno" no es tan privado como parece.

2Conceptos

3Explicación profunda

/proc no está en el disco: lo genera el kernel al vuelo. Cada proceso vivo tiene un directorio /proc/<pid> con archivos que son en realidad ventanas al estado del proceso. cmdline te da los argumentos con los que se lanzó; environ, su entorno; maps, las regiones de memoria y las bibliotecas cargadas; fd/, enlaces a cada archivo o socket abierto; exe, un enlace al binario en ejecución. Nada de esto es un fallo: es introspección legítima, la base de herramientas como ps, lsof o top. El problema de seguridad aparece por quién puede leerlo.

Por defecto puedes leer el /proc de tus propios procesos, y algunos campos de los ajenos. En un sistema donde varios usuarios comparten máquina, o donde una aplicación comprometida corre junto a otras, esto importa: si un proceso recibió un secreto por línea de comandos (mysql -pMiClave) o por entorno, ese secreto es legible para quien pueda mirar su /proc. Por eso pasar contraseñas como argumento está prohibido en cualquier guía seria, y por eso pasar secretos por variable de entorno, aunque es mejor que el argumento, tampoco es privado frente a quien comparte la máquina con los privilegios adecuados.

La segunda mitad de la lección es la herencia que decide qué se ejecuta. Cuando escribes tar sin ruta, la shell recorre los directorios del PATH en orden y ejecuta el primer tar que encuentra. El orden es todo. Si el PATH es /opt/util:/usr/bin y /opt/util es escribible por un usuario cualquiera, ese usuario planta un /opt/util/tar con su código y lo ejecutará cualquier proceso que llame a tar por su nombre y tenga ese PATH. Es la razón por la que un directorio world-writable dentro del PATH es tan grave: convierte "escribir un archivo" en "ejecutar código en otro proceso". El clásico peligroso es el . (directorio actual) en el PATH: hace que cualquier carpeta en la que entres pueda contener un binario que suplante un comando común.

El entorno también secuestra la ejecución sin tocar el PATH. El enlazador dinámico lee variables como LD_PRELOAD y LD_LIBRARY_PATH. Con LD_PRELOAD apuntando a una biblioteca propia, esa biblioteca se carga antes que las del sistema y puede sustituir funciones estándar: el programa cree que llama a getuid() del sistema y llama a la tuya. El kernel protege el caso más grave —ignora LD_PRELOAD para binarios SUID— pero en procesos normales que heredan un entorno controlado por el atacante, es una vía directa a ejecutar su código dentro del proceso. La conclusión de diseño es dura y simple: el entorno de un proceso privilegiado es parte de su superficie de ataque, y hay que fijarlo, no heredarlo.

4Ejemplo sencillo

# Un cocinero que pide "el cuchillo" sin mirar de cuál se fía

El cocinero (proceso) grita "traedme el cuchillo" (tar, cp, id...).
Un ayudante recorre los cajones EN ORDEN (el PATH) y le trae el
primero que encuentre con ese nombre.

Si el primer cajon es de acceso publico (directorio world-writable
en el PATH), cualquiera deja ahi un "cuchillo" propio. El cocinero
lo usara sin darse cuenta, creyendo que es el de siempre.

# Y una libreta que el cocinero deja abierta

El cocinero anota en una libreta (environ) las claves de la caja
fuerte que le dieron al empezar. Cualquiera que pueda asomarse a su
puesto (/proc) lee esas claves mientras el cocinero trabaja.

5Ejemplo técnico

Mira lo que /proc filtra de un proceso y cómo se resuelve un comando por el PATH:

Los comandos que lo hacen concreto. El primero enseña el entorno del propio proceso; el segundo demuestra cómo el orden del PATH decide qué binario gana:

# el entorno con el que arranco este proceso (separado por NUL)
cat /proc/self/environ | tr '\0' '\n'

# qué 'tar' se ejecutaria: el primero del PATH, en orden
echo "$PATH"
which -a tar        # lista cada tar del PATH, por orden de prioridad

# un PATH con un directorio escribible delante es una via de ejecucion
# /opt/util:/usr/bin  -> un /opt/util/tar propio gana a /usr/bin/tar

6Diagrama

flowchart LR
    P[proceso root · llama a: backup] -->|busca en el PATH| R{primer match}
    R -->|gana| M[/opt/util/backup · world-writable/]
    R -.se ignora.-> L[/usr/bin/backup · legítimo/]

7Código

La defensa se escribe como configuración, no como intención. Un servicio se lanza con un PATH fijo y mínimo, llama a sus binarios por ruta absoluta y arranca con el entorno limpio de variables peligrosas:

#!/usr/bin/env bash
# arranque endurecido de un servicio
set -euo pipefail

# 1) PATH fijo, minimo y sin directorios escribibles ni '.'
export PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'

# 2) limpiar variables que secuestran la carga de bibliotecas
unset LD_PRELOAD LD_LIBRARY_PATH LD_AUDIT

# 3) llamar a los binarios por ruta absoluta, no por nombre
/usr/bin/tar -czf /var/backups/datos.tgz /srv/datos

En systemd lo mismo se declara en la unit: Environment=PATH=... fija el PATH, y las directivas de aislamiento (que ves en la lección de systemd) evitan que el servicio herede un entorno del que no te fías. La regla práctica: un proceso privilegiado nunca debe usar el PATH ni el entorno que le llegue "por defecto"; los fija él.

8Qué puede salir mal

9Cómo lo abusaría un atacante

10Cómo defenderlo

11Laboratorio

12Ejercicios

set -euo pipefail
export PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
unset LD_PRELOAD LD_LIBRARY_PATH LD_AUDIT
/usr/bin/tar -czf /var/backups/d.tgz /srv/datos

printf '#!/bin/bash\necho SECUESTRADO como $(id -un)\n' > /opt/util/id
chmod +x /opt/util/id
PATH="/opt/util:$PATH" id     # ejecuta tu 'id', no /usr/bin/id

# debe fallar ahora: si puede escribir, la defensa no sirvio
touch /opt/util/prueba 2>/dev/null \
  && echo "FALLA: aun escribe" || echo "OK: sin escritura"
command -v id      # debe apuntar a /usr/bin/id

13Preguntas de comprensión

14Reto adicional

15Resumen

16Mis notas

17Recursos