COMMAND
sshd (scp)
SYSTEMS AFFECTED
SSH 1.2.xx, OpenSSH 2.2.0p1
PROBLEM
Michal Zalewski found following. 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, Michal 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. 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 we 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).
Note that script above will work much better for you once that You
remove all "of=/dev/stdout" from the script. All dd versions
have stdout as default output target, anyway. The new version
of script will create a 200 byte file alright:
#!/bin/bash
echo "D0755 0 ../../../../../../tmp/nope"
echo "D0755 0 ../../../../../../tmp"
echo "C4755 200 ScpIsBuggy"
dd if=/dev/urandom bs=200 count=1 2>/dev/null
dd if=/dev/zero bs=1 count=2 2>/dev/null
OpenSSH-1.2.1 appears to create the file wherever you tell it to,
but refuses to set setuid bit on it. That's not quite as bad as
SSH 1.2 (which will even conveniently allow setting arbitrary file
mode), but you can still overwrite ~/.ssh/authorized_keys or
similar files to the same effect, as you point you.
Openssh2.2.0p1 IS vulnerable, but some change is needed in fake
scp to exploit it. Using scripts above could make suid scpuser's
file in /tmp, but probably due to some protocol change in scp, the
file will be empty and scp will die with "lost connection".
Since openssh 2.2.0p1 is latest existing version, this bug
probably exist in every single scp version in the world.
SOLUTION
For Linux-Mandrake:
Linux-Mandrake 7.0: 7.0/RPMS/openssh-2.1.1p3-4mdk.i586.rpm
7.0/RPMS/openssh-askpass-2.1.1p3-4mdk.i586.rpm
7.0/RPMS/openssh-clients-2.1.1p3-4mdk.i586.rpm
7.0/RPMS/openssh-server-2.1.1p3-4mdk.i586.rpm
7.0/RPMS/openssl-0.9.5a-3mdk.i586.rpm
7.0/RPMS/openssl-devel-0.9.5a-3mdk.i586.rpm
7.0/SRPMS/openssh-2.1.1p3-4mdk.src.rpm
Linux-Mandrake 7.1: 7.1/RPMS/openssh-2.1.1p3-4mdk.i586.rpm
7.1/RPMS/openssh-askpass-2.1.1p3-4mdk.i586.rpm
7.1/RPMS/openssh-clients-2.1.1p3-4mdk.i586.rpm
7.1/RPMS/openssh-server-2.1.1p3-4mdk.i586.rpm
7.1/SRPMS/openssh-2.1.1p3-4mdk.src.rpm