Re: csh/tcsh vulnerabilityFrom: Valdis.Kletnieks@vt.edu
- Previous message: ash: "Re: Java and buffer overflows"
- In reply to: Á¤ ÈÆ¿µ: "csh/tcsh vulnerability"
- Next in thread: Idan l.: "Re: csh/tcsh vulnerability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: Á¤ ÈÆ¿µ <email@example.com> From: Valdis.Kletnieks@vt.edu Date: Thu, 27 Jun 2002 01:32:18 -0400
On Thu, 27 Jun 2002 03:41:57 -0000, =?ks_c_5601-1987?B?waQgyMa/tQ==?= <firstname.lastname@example.org> said:
> OS : Solaris 8
> [sf280r]#/home/dragory> bash
> [dragory@sf280r dragory]$ export HOME=`perl -e 'print "x"x5000'`
> [dragory@sf280r dragory]$ su
> Password:(input correct password)
So at this point, you could get root if you wanted, since you supplied the
CORRECT password. If you hadn't set $HOME, you'd have a perfectly valid
and authorized root shell.
> Segmentation Fault (core dumped)
> [dragory@sf280r dragory]$ ls -l core
> -rw------- 1 root 580464 Jun 27 12:29 core
> [sf280r]#/home/dragory> gdb -q tcsh core
> (no debugging symbols found)...Core was generated by `tcsh'.
> Program terminated with signal 11, Segmentation Fault.
> #0 0x29be4 in doglob ()
And once you *had* root, tcsh blew up because $HOME was bad. What I'd
consider poor form - it's generally impolite to crash if you're a shell. ;)
> Is this vulnerable?
Probably not - all you're managing to do is crash the shell that you
had already gained access to. To get a vulnerability out of it,
you would need to do one of two things:
1) Find a way to get /bin/su to core even if you *dont* supply the correct
2) Find some *other* way to get the system to run tcsh as root with a bad $HOME.
-- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
- application/pgp-signature attachment: stored