strace / dtrace / ltrace ... полезен для многих вещей, от поиска скрытых нарушений доступа до трассировки сетевых сокетов, но, возможно, он не может видеть все.
Я не смог выяснить, используя strace (он снова возник, когда я пытался ответить на другой вопрос сегодня), где sudo выделяет и сохраняет незашифрованные пароли в системной памяти. Связанный вопрос связан, если это новость для вас.
Наиболее близкий, который я получил, с такими следами (это может быть плохой пример, используя сложенное sudo; я пробовал несколько вещей):
$ sudo strace -ff -o mem sudo -s Enter password... строки такие:
mem.14471:stat("/etc/profile.d/gnome-ssh-askpass.sh", ) = 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 и я полагаю, что пытался отследить их по отдельности, даже заменив переменную env в / usr / libexec / openssh-askpass своим собственным strace, но безрезультатно.
Я умею читать и декодировать строки; Я могу следить за назначенными дескрипторами, кодами возврата и распределением памяти. Чего я не могу найти, так это разветвления, которое выделяет и сохраняет пароль sudo (до 7 раз) в памяти, пока sudo активен. Подтверждение резидентности пароля осуществляется с помощью LiME Forensics, примененной к CentOS.
В качестве альтернативы, будет ли лучший подход, как итерация распределения памяти процесса?
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.