Re: Compaq tru64 setuids /usr/bin/at and /usr/dt/bin/mailcv

[KF <dotslash () snosoft com>]

So at frame 4 am I looking at a malloc() issue?

# /usr/bin/at `perl -e 'print "A" x 9000'`

Memory fault - core dumped
# dbx /usr/bin/at core
dbx version 5.1
Type 'help' for help.
Core file created by program "at"

warning: /usr/bin/at has no symbol table -- very little is supported 
without it


signal Segmentation fault at >*[(unknown), 0x3ff801bc960]       ldq     
t2, 0(ra)
(dbx) where
>  0 (unknown)() [0x3ff801bc960]
  1 (unknown)() [0x3ff801bc5e4]
  2 (unknown)() [0x3ff801beb70]
  3 (unknown)() [0x3ff801bf2f4]
  4 malloc(0x0, 0x3ffc0087f58, 0x3ff801b14b0, 0x3ffc00997c0, 
0x13fff97f0) [0x3ff800cdad4]
  5 (unknown)() [0x3ff801b14ac]
  6 __localtime64_r(0x13fff97f0, 0x3ffc0087f58, 0x3ff801b1144, 
0x11fffa028, 0x14000a800) [0x3ff801b11e8]
  7 __Plocaltime64_r(0x3ff801b1144, 0x11fffa028, 0x14000a800, 
0x11fffa028, 0x3ff801a7934) [0x3ff801b1140]
  8 __localtime64(0x14000a800, 0x11fffa028, 0x3ff801a7934, 0x14000a800, 
0x3ff800d040c) [0x3ff801a7930]
  9 localtime(0x3ff801a7934, 0x14000a800, 0x3ff800d040c, 0x11fff9dd8, 
0x1200049ec) [0x3ff800d0408]

-KF

Foldi Tamas wrote:

> On Wed, Mar 27, 2002 at 11:58:01AM -0500, KF wrote:
>
> > Not really sure... the ladebug debugger gave me a head ache so I didn't 
> > play with it much. If someone can point
>
> Try with the dbx debugger instead of ladebug.
>
> > me to a working tru64 gdb package I would find out some details. I was 
> > hoping that someone else from the
> > list would be able to determine just that...is local root compromise 
> > possible?
> > -KF
> >
> > > alpha.snosoft.com> uname -a
> > > OSF1 alpha.snosoft.com V5.1 732 alpha
> > >
> > > alpha.snosoft.com> ls -al /usr/bin/at
> > > -rwsr-xr-x   1 root     bin        57760 Aug 24  2000 /usr/bin/at
> > >
> > > alpha.snosoft.com> /usr/bin/at `perl -e 'print "A" x 9000'` Memory fault
> > > - core dumped
>
> [crow@darksun]% uname -a                               /usr/users/crow/
> OSF1 darksun V5.1 1885 alpha
> [crow@darksun]% ls -l /usr/bin/at                      /usr/users/crow/
> -rwsr-xr-x   1 root     bin        57840 Aug  1  2001 /usr/bin/at
> [crow@darksun]%  /usr/bin/at `perl -e 'print "A" x 9000'`
> at: syntax error                   
>                                             
> (it seems the bug is fixed in 5.1A)
>
> > > alpha.snosoft.com> ls -al /usr/dt/bin/mailcv
> > > -rwsr-xr-x   1 root     bin        98368 Aug 25  2000 /usr/dt/bin/mailcv
> > >
> > > alpha.snosoft.com> /usr/dt/bin/mailcv -f  `perl -e 'print "A" x 9000'` A
> > > exception system:  exiting due to multiple internal errors:
> > >      exception dispatch or unwind stuck in infinite loop
> > >      exception dispatch or unwind stuck in infinite loop exception
> > > system:  exiting due to multiple internal errors:
> > >      exception dispatch or unwind stuck in infinite loop
> > >      exception dispatch or unwind stuck in infinite loop Abort - core
> > > dumped
>
> [crow@darksun]% /usr/dt/bin/mailcv -f  `perl -e 'print "A" x 9000'` A
> exception system:  exiting due to multiple internal errors:
>        exception dispatch or unwind stuck in infinite loop
>        exception dispatch or unwind stuck in infinite loop
> exception system:  exiting due to multiple internal errors:
>        exception dispatch or unwind stuck in infinite loop
>        exception dispatch or unwind stuck in infinite loop
> zsh: abort (core dumped)  /usr/dt/bin/mailcv -f `perl -e 'print "A" x 9000'` A
>
> [crow@darksun]% dbx /usr/dt/bin/mailcv core   
> dbx version 5.1
> Type 'help' for help.
> Core file created by program "mailcv"
>
> warning: /usr/dt/bin/mailcv has no symbol table -- very little is supported
> without it
> thread 0x4 signal IOT/Abort trap at >*[_sigprocmask, 0x3ff800d5708]     bne
> a3, 0x3ff800d5710
> (dbx) where
>
> > 0 _sigprocmask(0x3ff00000001, 0x0, 0x3ff801229d8, 0x40c6666600000006,
> > 0x3ff801869b4) [0x3ff800d5708]
>   1 __sigprocmask(0x3ff801229d8, 0x40c6666600000006, 0x3ff801869b4, 0x0,
> 0x3ff801a9cd4) [0x3ff800d7d70]
>   2 abort(0x3ff807e2364, 0x20, 0x0, 0x0, 0x600000000) [0x3ff801a9cd0]
>   3 __exc_raise_status_exception(0x0, 0x0, 0x0, 0x0, 0x3ff800bedc8)
> [0x3ff807e2360]
> [...]
>  19 exc_raise_status_exception(0x0, 0x0, 0x0, 0x4000, 0x3ff807e320c)
> [0x3ff807e23e0]
>  20 exc_dispatch_exception(0x3ffc00819c0, 0xc, 0x11fff8a40, 0x6, 0x1)
> [0x3ff807e3208]
>  21 exc_raise_signal_exception(0xb0ffe0003, 0x80, 0x0, 0x3ff800e8f8c, 0x1)
> [0x3ff807e3e68]
>  22 (unknown)() [0x3ff80577d80]
>  23 __getopt(0x3ffc0099f18, 0x0, 0x0, 0x0, 0x0) [0x3ff800e8f8c]
> (dbx) 
>
> As i see, this is not a buffer overflow (getopt called with NULL pointers).
>
>
> Btw, before you start coding exploit to alpha/tru64, you should check the
> "executable_stack" setting with "sysconfig -q proc executable_stack". If it is
> null, then the exploiting is much harder. 
>
> Regards,
> Tamas Foldi
>
> >