Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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"
share|improve this question
    
@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
3  
They wouldn't need strace for that... alias su="/foo/myscript_that_just_captures_passwords" –  jordanm Nov 7 '12 at 18:14
add comment

3 Answers

up vote 13 down vote accepted

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

share|improve this answer
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
    
That was really helpful, thanks! –  Joseph R. Nov 7 '12 at 18:15
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
show 4 more comments

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.

share|improve this answer
add comment

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
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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