(from BugTraq) openssh2.2.p1 - Re: scp file transfer hole

[Chiaki Ishikawa]

X-PMC-CI-e-mail-id: 13726 

Hi, 


I have been a successful user of Openssh for some time.

I am attaching two articles from BugTraq.
Hopefully, they show exactly the security problems
reported in the BugTraq mailing list.
[Pity that no one seemed to have bothered to contact the
mailing list(s) for openssh development.]

I am not sure what the right fixes would be.
But at least, people need to be made aware of the problem
first.

Interested readers are encouraged to look at BugTraq
mailing list archives found in the web across the world.

(1)

(Before this post there was a post from Zalewski, which
is quoted in this e-mail post.)

Date:         Sun, 1 Oct 2000 12:19:46 +0200
Reply-To: Martin MaD Douda <martin at DOUDA.NET>
Sender: Bugtraq List <BUGTRAQ at SECURITYFOCUS.COM>
From: Martin MaD Douda <martin at DOUDA.NET>
Subject:      openssh2.2.p1 - Re: scp file transfer hole
To: BUGTRAQ at SECURITYFOCUS.COM
In-Reply-To:  <Pine.LNX.4.10.10009302120460.852-100000 at localhost>

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 at 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 at douda.net>, <mad at gate.mobil.cz> (160 characters only)
PGP:ID=0x6FE43023 Fingerprint:E495 11DA EF6E 0DD6 965A 54F3 888E CC9E 6FE4 3023
--------------------------------------------------------------------------------
[1]+  Done               rm -rf /


(2)

Date:         Sun, 1 Oct 2000 00:43:39 -0400
Reply-To: stanislav shalunov <shalunov at INTERNET2.EDU>
Sender: Bugtraq List <BUGTRAQ at SECURITYFOCUS.COM>
From: stanislav shalunov <shalunov at INTERNET2.EDU>
Subject:      Re: scp file transfer hole
To: BUGTRAQ at SECURITYFOCUS.COM
In-Reply-To:  <Pine.LNX.4.10.10009302120460.852-100000 at localhost>

Michal Zalewski <lcamtuf at TPI.PL> writes:

> 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.

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.

Very disturbing--this is supposed to be security software.

--
Stanislav Shalunov <shalunov at internet2.edu>	Internet Engineer, Internet2

A language that doesn't have everything is actually easier to program
in than some that do.                            -- Dennis M. Ritchie