strace to discover sudo password persistence location

Question

strace/dtrace/ltrace ... useful for lots of things, from finding hidden access violations to network socket tracing, but maybe it can't see all.

I haven't been able to figure out using strace (it came up again as I was trying to answer another question today) where sudo allocates and persists plaintext passwords in system memory. The linked question is related if this is news to you.

The closest I've gotten, with traces like this (this might be a bad example, using a stacked sudo; I've tried a few things):

$ sudo strace -ff -o mem sudo -s
Enter password...

are lines like this:

mem.14471:stat("/etc/profile.d/gnome-ssh-askpass.sh", {st_mode=S_IFREG|0644, st_size=70, ...}) = 0
mem.14471:access("/etc/profile.d/gnome-ssh-askpass.sh", R_OK) = 0
mem.14471:open("/etc/profile.d/gnome-ssh-askpass.sh", O_RDONLY) = 3
mem.14471:read(3, "SSH_ASKPASS=/usr/libexec/openssh"..., 70) = 70

and I believe I tried tracing those individually, even replacing the env variable in /usr/libexec/openssh-askpass with its own strace, to no avail.

I know how to read and decode straces; I can follow the assigned handles, return codes and memory allocations. What I can't find is a fork that allocates and persists the sudo password (up to 7 times) in memory, while sudo is active. Proof the password's resident is via LiME Forensics applied to CentOS.

Alternatively, would there be a better approach, like iterating process memory allocations?

Answer 1

strace isn't going to show anything as specific as this. The closest you can get is the brk() or mmap(MAP_ANONYMOUS) calls which glibc uses to grab a whole new memory region. The rest doesn't use system calls, just direct memory access.

You might try ltrace for userspace library calls.

Or just find the password prompt in the source code and look what happens with its results. Add a few printf()'s to display the memory addresses.