I'm currently fascinated by strace so, being new to it, I decided to play around a little. As suggested by the question title, I tried both strace su and strace ssh. Both commands displayed the password I typed in the strace output. su kept complaining of an incorrect password while ssh managed to log in normally.
My questions:

  • Is this a security flaw or am I missing something?
  • Is su reporting an incorrect password as a security measure because it detected it was being run through strace? If so how can it tell that it's being invoked through strace? Does it check /proc/self/cmdline maybe?
  • How much damage can be caused by something like
    alias su="strace -o /tmp/output.log su"
  • @FloppyDisk, I know that. What I'm saying is: shouldn't this be prevented somehow? – Joseph R. Nov 7 '12 at 18:00
  • 2
    User's can only trace their own processes, with the exception of root. In Linux, you can disable a users ability to call ptrace() via CAP_SYS_PTRACE capability. – jordanm Nov 7 '12 at 18:10
  • Yes but a user can be misled into aliasing su by a malware script. – Joseph R. Nov 7 '12 at 18:12
  • 4
    They wouldn't need strace for that... alias su="/foo/myscript_that_just_captures_passwords" – jordanm Nov 7 '12 at 18:14

It's not a security flaw; you're able to strace the process because it's your process. You can't just attach strace to any running process. For example:

$ sudo sleep 30 &
[1] 3660

$ strace -p 3660
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted

su is reporting an incorrect password because it doesn't have sufficient permission to read /etc/shadow anymore. /etc/shadow is where your password hash is stored, and it's set so only root can read it for security reasons. su has the setuid bit set so it will be effectively run as root no matter who runs it, but when you run it through strace that doesn't work, so it ends up running under your account

I'm not sure what you mean by "how much damage could be caused". As you saw, su doesn't work from within strace, so you're going to render it nonfunctional. If you mean "could somebody use this to steal my password", they would need the ability to set aliases in your shell, which they shouldn't have permission to do unless you've made your login files world-writable or something similar. If they did have permission to set aliases, they could just alias su to a patched version that records your password directly; there's nothing special about strace

  • 3
    Strace does support attaching to a running process via the -p option. Outside of that, this is a good answer, still a +1. – jordanm Nov 7 '12 at 18:12
  • @jordanm My man page skimming skills need work. Updated, thanks – Michael Mrozek Nov 7 '12 at 18:13
  • One more thing, since you brought up setuid, I thought that most modern distros disable elevating privileges via the setuid bit. How are programs like su exempted from this rule? – Joseph R. Nov 7 '12 at 18:19
  • 1
    @JosephR. Do you have a source for that? Linux ignores setuid on shell scripts, but it's pretty essential for binaries; I've never heard of it being disabled altogether – Michael Mrozek Nov 7 '12 at 18:25
  • 2
    @JosephR. IIRC that was just a roadmap for Fedora, to remove all setuid binaries and replace the functionality with SELinux policies. I am not aware of any other distros that planned to do that – jordanm Nov 7 '12 at 18:37

I believe the reason you are seeing this is because you have to enter the su and ssh passwords in plain text prior to them being hashed and processed. When you run strace, you're picking up all the system calls and it catches the plaintext password prior to it being hashed and processed. Just because the terminal doesn't show text doesn't mean you aren't entering plain text.


http://blog.vpetkov.net/2013/01/29/sniffing-ssh-password-from-the-server-side/ suggests there is a potential security problem in that if attackers have root privileges on a server running openssh, they could gather the passwords of people who ssh to the server by running strace on the "net" process:

ps aux | grep ssh | grep net | awk {‘ print $2′} | xargs -L1 strace -e write -p


Process 17681 attached – interrupt to quit
write(4, “\0\0\0 \v”, 5) = 5
write(4, “\0\0\0\33thisismysupersecretpassword“, 31) = 31
write(3, “\345+\275\373q:J\254\343\300\30I\216$\260y\276\302\353″…, 64) = 64
Process 17681 detached
  • 2
    When a hacker has root access to a (landing) server where authentication takes place, strace is the least of your problems. – Bananguin Jun 6 '16 at 7:30

Even though this can only be done with root privilege, but it's still very dangerous: you use ssh from that machine to access other critical machines, then a malicious person with root privilege steal your password or pass phrase without you knowing it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.