Re: csh core dumping 7.0-rc1

On Jan 11, 2008, at 7:19 PM, Chris wrote:

> After rebooting a FreeBSD 7.0-RC1 server I noticed I could not login
> as root either via ssh or su, I initially thought I forgot my password
> but soon noticed that csh was crashing.  After reading advice its
> always safe to keep the default shell for root user I have kept it on
> all my servers but now this supposedbly safe option has prevented me
> from logging in.
>
> Luckily I had enabled root login (via keys) on sshd and added my ssh
> key to the root .ssh dir and then logged in as toor over ssh which was
> using /bin/sh.
>
> I have gone through rebuilding world, I am not using any unsafe flags
> in /etc/make.conf in fact using default compile flags but after all
> this when running csh it core dumps.
>
> ~ # csh
> Segmentation fault: 11 (core dumped)
>
> however /rescue/csh works.
>
> I ran ldd to check what its compiled against.
>
> # ldd /bin/csh
> /bin/csh:
>         libncurses.so.7 => /lib/libncurses.so.7 (0x280c5000)
>         libcrypt.so.4 => /lib/libcrypt.so.4 (0x28108000)
>         libc.so.7 => /lib/libc.so.7 (0x28121000)
>
> all the above 3 files exist.
>
> the rescue binary is static.
>
> 1 - Is the rescue csh version the same as the one in the base system
> with the only difference its statically compiled?
>
> 2 - Is it safe and a workaround to copy the /rescue/csh to /bin/csh?
>
> 3 - Is this a known problem? if not I can do a PR as this is
> potentially a serious issue if I had no backdoor way in setup with
> toor I would have been locked out of a remote server with the
> situation of having to pay a premium for a kvm to get myself back in.
>
> not sure if using gbd properly but I ran it and see this.
>
> This GDB was configured as "i386-marcel-freebsd"...(no debugging
> symbols found)...
> Core was generated by `csh'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /lib/libncurses.so.7...(no debugging symbols  
> found)...done.
> Loaded symbols for /lib/libncurses.so.7
> Reading symbols from /lib/libcrypt.so.4...(no debugging symbols  
> found)...done.
> Loaded symbols for /lib/libcrypt.so.4
> Reading symbols from /lib/libc.so.7...(no debugging symbols  
> found)...done.
> Loaded symbols for /lib/libc.so.7
> Reading symbols from /usr/local/lib/libiconv.so...done.
> Loaded symbols for /usr/local/lib/libiconv.so
> Reading symbols from /libexec/ld-elf.so.1...done.
> Loaded symbols for /libexec/ld-elf.so.1
> #0  0x00000000 in ?? ()
>
> bt shows this
>
> #0  0x00000000 in ?? ()
> #1  0x08057c65 in ?? ()
> #2  0x281f7b08 in in6addr_linklocal_allnodes () from /lib/libc.so.7
> #3  0x0808c120 in ?? ()
> #4  0x00000001 in ?? ()
> #5  0x0808c120 in ?? ()
> #6  0xbfbfed20 in ?? ()
> #7  0x00000001 in ?? ()
> #8  0xbfbfecd8 in ?? ()
> #9  0x0804bf7a in ?? ()
> #10 0x00000002 in ?? ()
> #11 0x0808c0c5 in ?? ()
> #12 0xbfbfeb48 in ?? ()
> #13 0x280988a6 in dlopen () from /libexec/ld-elf.so.1
> Previous frame inner to this frame (corrupt stack?)
>
> Chris

I'd ldd libcrypt, libncurses, and libiconv, just to be sure..
-Garrett