Re: TCSH problems?

From: KF (dotslashat_private)
Date: Wed Jun 06 2001 - 05:25:58 PDT

  • Next message: max: "Re: proof of exploited code"

    I really didn't provide any examples for the other shells when I posted
    because 
    the behvior was all very similar for the long HOME variable... 
    here is some output from sco 
    
    # uname -a
    SCO_SV frodev 3.2 5.0.6 i386
    # HOME=`perl -e 'print "A" x 7000'`
    # export HOME
    # /bin/csh
    # cd ~
    Arguments too long.
    # exit
    # Memory fault - core dumped
    This GDB was configured as "i486-unknown-sco3.2v5.0.0elf"...
    (no debugging symbols found)...
    Core was generated by `csh'.
    Program terminated with signal 11, Segmentation fault.
    Reading symbols from /usr/lib/libsocket.so.1...(no debugging symbols
    found)...
    done.
    Reading symbols from /usr/lib/libc.so.1...(no debugging symbols
    found)...done.
    #0  0x41414141 in ?? ()
    
    and on sparc it crashes as soon as the env is set.
    [12:34pm]@[medusa]#uname -a
    SunOS medusa 5.7 Generic_106541-12 sun4m sparc SUNW,SPARCstation-5
    [12:34pm]@[medusa]#gdb tcsh 
    GNU gdb 4.18   
    (gdb) run 
    Starting program: /usr/local/bin/tcsh
    (no debugging symbols found)...(no debugging symbols found)...
    (no debugging symbols found)...(no debugging symbols found)...
    (no debugging symbols found)...(no debugging symbols found)...
    [12:35pm]@[medusa]#setenv HOME `perl -e 'print "A" x 7000'`P
     
    Program received signal SIGABRT, Aborted.
    0xef618444 in _libc_kill () from /usr/lib/libc.so.1
    (gdb) bt
    #0  0xef618444 in _libc_kill () from /usr/lib/libc.so.1
    #1  0xef5b9470 in abort () from /usr/lib/libc.so.1
    #2  0x21fd0 in dcanon ()
    #3  0x2a68c in dosetenv ()
    #4  0x38a50 in execute ()
    #5  0x38c78 in execute ()
    #6  0x1f360 in process ()
    #7  0x1e164 in main ()
    
    and regular csh 
    # HOME=`perl -e 'print "A" x 7000'`
    # export HOME
    # csh
    [1] + Segmentation Fault - core dumped csh
    #0  0x2e2f8 in ?? ()
    (gdb) bt
    #0  0x2e2f8 in ?? ()
    #1  0x21aec in ?? ()
    #2  0x21878 in ?? ()
    #3  0x22b8c in ?? ()
    Cannot access memory at address 0x79.
    
    And a side note while telneting to my sunos box to test tcsh and bash
    there I noticed 
    that telnet on sco does not like the long HOME variable either =]
    
    # telnet xxx.xxx.com
    Trying xxx.xxx.xxx.xxx...
    Memory fault - core dumped
    Core was generated by `telnet'.
    Program terminated with signal 11, Segmentation fault.
    Reading symbols from /usr/lib/libndbm.so...(no debugging symbols
    found)...done. Reading symbols from /usr/lib/libsocket.so.1...(no
    debugging symbols found)...
    done.
    Reading symbols from /usr/lib/libc.so.1...(no debugging symbols
    found)...done.
    #0  0x8001a2cc in _findiop () from /usr/lib/libc.so.1
    (gdb) bt
    #0  0x8001a2cc in _findiop () from /usr/lib/libc.so.1
    #1  0x80020d69 in fopen () from /usr/lib/libc.so.1
    #2  0x6568 in _filbuf ()
    #3  0x5f35 in _filbuf ()
    #4  0x6ed2 in _filbuf ()
    #5  0x25db in _filbuf ()
    (gdb) info registers
    eax            0x0      0
    ecx            0x41414141       1094795585
    edx            0x0      0
    ebx            0x8005b354       -2147110060
    esp            0x7fffe194       0x7fffe194
    ebp            0x7fffe1a4       0x7fffe1a4
    esi            0x212e8  135912
    edi            0x41414141       1094795585
    eip            0x8001a2cc       0x8001a2cc
    > 
    > Yeah see my post from a few hours before... titled "bash overflows"
    > 
    > I have seen at least one post for linux bash overflows but not much
    > follow up for other OS's.
    > http://www.securityfocus.com/frames/?content=/templates/archive.pike%3Flist%
    > 3D1%26tid%3D13697%26end%3D2001-06-09%26threads%3D0%26start%3D2001-06-03%26
    > This seems to affect bash and csh and tcsh on SCO and SunOS both.
    > 
    > ... gdb dumps are provided with my mailing...
    > -KF
    > 
    > Alex wrote:
    > >
    > >         After some ktracing, and code auditing by myself and a colleague,
    > > we believe the problem *may* infact be in libc's setenv() and getenv()
    > > functions.  We were able to duplicate the bug on various platforms, mostly
    > > causing signal 6s and dumping cores.  Feedback would be appreciated
    > >
    > > > > setenv HOME `perl -e 'print "/" x 10000'`
    > >
    > >                                         ^ Length varies from 1024-10000
    > > for effectiveness on diffrent OSes.
    > >
    > > -Alex
    



    This archive was generated by hypermail 2b30 : Wed Jun 06 2001 - 11:40:02 PDT