[16993] in bugtraq

home help back first fref pref prev next nref lref last post

rcp file transfer hole (was: scp file transfer hole)

daemon@ATHENA.MIT.EDU (Markus Friedl)
Mon Oct 2 12:51:42 2000

Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id:  <20001002130658.A5228@faui02.informatik.uni-erlangen.de>
Date:         Mon, 2 Oct 2000 13:06:58 +0200
Reply-To: Markus Friedl <Markus.Friedl@INFORMATIK.UNI-ERLANGEN.DE>
From: Markus Friedl <Markus.Friedl@INFORMATIK.UNI-ERLANGEN.DE>
X-To:         Michal Zalewski <lcamtuf@TPI.PL>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <Pine.LNX.4.10.10009302120460.852-100000@localhost>; from
              lcamtuf@TPI.PL on Sat, Sep 30, 2000 at 09:21:17PM +0200

On Sat, Sep 30, 2000 at 09:21:17PM +0200, 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).

well, this is not a scp problem.  it's a rcp problem.  scp is nothing
but the plain old rcp protocol over ssh instead of rsh, in the same
way you can do 'cvs' or 'rsync' over ssh.

so all secure-shell's derived from the original ssh-1.2.x releases
suffer from this problem (including openssh). however, ssh-2.x uses a
different protocol and is not vulnerable to this specific bug.

how should this be fixed in a reasonable way?  i don't think questions
similar to "do you really want to create /bla/bla/bla? (yes/no)" would
be useful.

-markus

home help back first fref pref prev next nref lref last post