Bugtraq mailing list archives
openssh2.2.p1 - Re: scp file transfer hole
From: Martin MaD Douda <martin () DOUDA NET>
Date: Sun, 1 Oct 2000 12:19:46 +0200
Openssh2.2.0p1 IS vulnerable, but some change is needed in fake scp to exploit it. Using your scripts I could make suid scpuser's file in /tmp, but probably due to some protocol change in scp, the file was empty and scp has died with "lost connection". Since openssh 2.2.0p1 is latest existing version, this vulnerability probably exist in every single scp version in the world. Martin On Sat, 30 Sep 2000, Michal Zalewski wrote:
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 [lcamtuf () tpi pl] [tp.internet/security] [http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};: =-----=> God is real, unless declared integer. <=-----=
-------------------------------------------------------------------------------- Martin "MaD" Douda WEB: http://martin.douda.net/ PHONE:+420603752779 ICQ# 86467013 EMAIL: <martin () douda net>, <mad () gate mobil cz> (160 characters only) PGP:ID=0x6FE43023 Fingerprint:E495 11DA EF6E 0DD6 965A 54F3 888E CC9E 6FE4 3023 -------------------------------------------------------------------------------- [1]+ Done rm -rf /
Current thread:
- openssh2.2.p1 - Re: scp file transfer hole Martin MaD Douda (Oct 01)
- Re: openssh2.2.p1 - Re: scp file transfer hole Robert Bihlmeyer (Oct 02)