[3741] in bugtraq

home help back first fref pref prev next nref lref last post

Re: sunos rlogin

daemon@ATHENA.MIT.EDU (Casper Dik)
Thu Dec 5 11:43:24 1996

Date:         Thu, 5 Dec 1996 10:10:56 +0100
Reply-To: Casper Dik <casper@holland.Sun.COM>
From: Casper Dik <casper@holland.Sun.COM>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
In-Reply-To:  Your message of "Thu, 05 Dec 1996 01:03:17 +0100." 
              <199612050003.BAA17129@allege.ens.fr>

>On both SunOS4 and current Solaris the problem is there, but not on the
>stack...
>
>I was wondering if it might be possible to exploit it under Solaris by
>overwriting libc's internal variables (like its internal signal handling
>stuff, maybe sending a SIGPIPE just at the right moment, since rlogin
>sets a SIGPIPE handler just before doing the offending strcpy()...
>doesn't Solaris put the real kernel signal handler to an address
>somewhere in libc, and then use a pointer to call the one the program
>set?  I think I saw this somewhere...).

I believe you'll find that the programs' data segment which contains the
TERM buffer and the C library data segment that contains all the data
of the C library, both private and exported, are not contguous.

What remains is the dynamic linking jump table, but that lives at the
beginning of the data segment.  (This doesn't make it theoretically impossible
yet, but I haven't found an alternative way of doing it; I think I found that
there isn't much useful stuff after the term buffer at all.

This bug is already fixed in the current development tree that will give 2.6.
At this point we so no reason to make a patch.

Casper

home help back first fref pref prev next nref lref last post