5

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"
Joseph R.
  • 39,549
  • @FloppyDisk, I know that. What I'm saying is: shouldn't this be prevented somehow? – Joseph R. Nov 07 '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 07 '12 at 18:10
  • Yes but a user can be misled into aliasing su by a malware script. – Joseph R. Nov 07 '12 at 18:12
  • 4
    They wouldn't need strace for that... alias su="/foo/myscript_that_just_captures_passwords" – jordanm Nov 07 '12 at 18:14

4 Answers4

18

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

Michael Mrozek
  • 93,103
  • 40
  • 240
  • 233
  • 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 07 '12 at 18:12
  • @jordanm My man page skimming skills need work. Updated, thanks – Michael Mrozek Nov 07 '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 07 '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 07 '12 at 18:25
  • I see. I stand corrected. Thanks for your enlightening answers... – Joseph R. Nov 07 '12 at 18:26
  • 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 07 '12 at 18:37
  • @jordanm this SELinux-stuff sounds interesting. Are you willing to answer a follow-up-question about that? – Nils Nov 07 '12 at 21:11
  • @Nils actually, yes, I found the relevant information. The goal was actually to use file system capabilities, not SELinux though. – jordanm Nov 07 '12 at 22:09
3

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.

Nils
  • 18,492
FloppyDisk
  • 328
2

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
Philip Durbin
  • 909
  • 2
    When a hacker has root access to a (landing) server where authentication takes place, strace is the least of your problems. – Bananguin Jun 06 '16 at 07:30
0

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.

wzis
  • 1