Since my mail got rejected for unknown reasons to vuln-dev I'd like to use this list as a backup to explain to everybody interested what's happening with bash:
----- Original Message ----- From: "Berend-Jan Wever" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, February 13, 2003 18:33 Subject: Re: Bash Blues. > I tested it: it a globbing bug; `perl -e 'print "*/" x 2860'` is the minimal > that works for my bash (GNU bash, version 2.05a.0(1)-release > (i386-pc-linux-gnu)). > > My bash just runs out of stack; it SIGSEGV's on a push with esp = 0xbf800000 > > Berend-Jan Wever > > babyjee@papa:~$ gdb bash > ... > (gdb) run > ... > babyjee@papa:~$ `perl -e 'print "*/" x 2860'` > (no debugging symbols found)...(no debugging symbols found)... > Program received signal SIGSEGV, Segmentation fault. > 0x400c71c8 in malloc () from /lib/libc.so.6 > (gdb) info reg > eax 0x4016e6a0 1075242656 > ecx 0xbf800084 -1082130300 > edx 0x10 16 > ebx 0x40170e48 1075252808 > esp 0xbf800000 0xbf800000 > ebp 0xbf80002c 0xbf80002c > esi 0x4016e6a0 1075242656 > edi 0x4016e6a0 1075242656 > eip 0x400c71c8 0x400c71c8 > eflags 0x10206 66054 > cs 0x23 35 > ss 0x2b 43 > ds 0x2b 43 > es 0x2b 43 > fs 0x0 0 > gs 0x0 0 > fctrl 0x37f 895 > fstat 0x0 0 > ftag 0xffff 65535 > fiseg 0x0 0 > fioff 0x0 0 > foseg 0x0 0 > fooff 0x0 0 > ---Type <return> to continue, or q <return> to quit---q > Quit > (gdb) disass $eip-0x20 $eip+0x20 > Dump of assembler code from 0x400c71a8 to 0x400c71e8: > 0x400c71a8 <malloc+536>: jmp 0x400c71ba <malloc+554> > 0x400c71aa <malloc+538>: lea 0x0(%esi),%esi > 0x400c71b0 <malloc+544>: movl $0x0,0x410(%esi) > 0x400c71ba <malloc+554>: lea 0x8(%edi),%eax > 0x400c71bd <malloc+557>: lea 0xffffffd8(%ebp),%esp > 0x400c71c0 <malloc+560>: pop %ebx > 0x400c71c1 <malloc+561>: pop %esi > 0x400c71c2 <malloc+562>: pop %edi > 0x400c71c3 <malloc+563>: leave > 0x400c71c4 <malloc+564>: ret > 0x400c71c5 <malloc+565>: lea 0x0(%esi),%esi > 0x400c71c8 <malloc+568>: push %ebp > 0x400c71c9 <malloc+569>: mov %esp,%ebp > 0x400c71cb <malloc+571>: sub $0x4c,%esp > 0x400c71ce <malloc+574>: push %edi > 0x400c71cf <malloc+575>: push %esi > 0x400c71d0 <malloc+576>: push %ebx > 0x400c71d1 <malloc+577>: call 0x400c71d6 <malloc+582> > 0x400c71d6 <malloc+582>: pop %ebx > 0x400c71d7 <malloc+583>: add $0xa9c72,%ebx > 0x400c71dd <malloc+589>: mov %eax,0xfffffffc(%ebp) > 0x400c71e0 <malloc+592>: mov %edx,0xfffffff8(%ebp) > ---Type <return> to continue, or q <return> to quit--- > 0x400c71e3 <malloc+595>: cmp $0x1f7,%edx > End of assembler dump. > > > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, February 13, 2003 15:26 > Subject: Bash Blues. > > > > [ Moderator: Post Edited Accordingly ] > > > > uk2sec /bin/bash Advisory > > > > By sending a perl request on the GNU bash terminal we can cause a > > Segmentation Fault. > > > > Work done was based on: > > GNU bash, version 2.05a.0(1)-release (i686-pc-linux-gnu) > > (Redhat 7.3) > > > > The basis for this advisory is theoretical - Although not a current > > security risk, a technique yet to be developed may allow exploitation. > > > > Background: > > > > During some work, I noticed GNU bash could be crashed by sending a > > malformed perl request to the terminal. > > > > example: `perl -e 'print "*/*" x 3500'` > > <bash crashes> > > > > (exact amount is: `perl -e 'print "*/*" x 2338'`) > > > > This crash overwrites the ecx register on X86 (linux RH 7.3) systems, and > > r23 on HPUX (11.00). > > > > X86: ecx: 0x2f2f2f2f 791621423 > > HPUX r23: 2f2f2f2f00001e6e > > > > This overflow may allow us to execute arbitrary code with the uid of the > > person who crashes the shell. Since bash is not suid, this isn't a big > > problem unless a special exploitation method can be created. > > > > To reproduce the seg fault, you must enclose the perl request with ` ` . > > > > ` perl -e.... etc.. ` CORRECT > > perl -e.... etc.. DOESN'T WORK > > > > We have looked at ways to generate an exploit for this, however so far > > nothing 'obvious' has been found. We tried creating a deep directory > > structure which would be followed by something like a /tmp directory > > watcher, however we are unable to create a directory 3500 folders deep. > > Perhaps something with sym-links could be used to do this, and the > > directory structure could contain our executable asm code.? Not tested, > > just thoughts. > > > > Furthermore we found several ways decrese the performance of a linux > > machine to almost a stand still, however that is not part of this > > advisory and can be disabled using resource limits on the server. For > > more information feel free to contact [EMAIL PROTECTED] > > > > Thanks for your time, > > > > uk2sec > > > > c0wd0g. > > > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > > Memebers: > > c0w_d0g (c0w_d0g3|@|yahoo.co.uk), deadbeat (deadbeat|@|hush.com). > > > > > > > > > > > > _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html