Lesson 1.72: Secrets in process memory and ptrace
A running program keeps its secrets in memory: tokens, passwords, decrypted keys. Any process that can attach to it with ptrace (the debugger interface) can copy all of that out. Linux's Yama module decides who may attach. In the lab a 'temporary' setting from a debugging ticket has opened every developer process on a shared jump host to every other process of the same user. You prove the risk with gcore, find the file that caused it, restore the default and then tighten it for this host.
16 min
You will learn to
- Explain what ptrace gives an attacker
- Read and set kernel.yama.ptrace_scope (0, 1, 2, 3)
- Find which sysctl.d file sets a value
- Dump a process's memory with gcore and search it
- Choose a ptrace scope for a server
Key terms
- ptrace
- The system call debuggers use to stop a process, read and write its memory and registers.
- Yama ptrace_scope
- Kernel setting for who may attach: 0 same user, 1 only parents, 2 only CAP_SYS_PTRACE, 3 nobody.
- gcore
- gdb's tool that writes a running process's memory to a core file without stopping it for long.
- sysctl.d order
- Files are applied in name order; the last value for a key wins.
- CAP_SYS_PTRACE
- The capability that lets a process trace processes it otherwise couldn't.
← journalctl in depth: filtering the journal · All lessons · Reading the journal across boots →