[4960] in bugtraq

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

Re: Solaris ld.so possibly vulnerable?

daemon@ATHENA.MIT.EDU (Adam Morrison)
Mon Jul 21 16:30:41 1997

Date: 	Mon, 21 Jul 1997 22:43:02 +0300
Reply-To: Adam Morrison <adam@MATH.TAU.AC.IL>
From: Adam Morrison <adam@MATH.TAU.AC.IL>
X-To:         dan@DIMSUM.TCH.HARVARD.EDU
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <Pine.SOL.3.96.970718113641.8794A-100000@dimsum> from "Dan
              Fleisher" at Jul 18, 97 11:40:28 am

> Hi, here is the results of a test which indicate that Solaris (2.4 at
> least) ld.so might be vulnerable to this overflow:

I don't think that the Solaris and Linux ld.so share the same code
base, so I doubt there'll be a case where you could say ``this overflow''
about them.

As for the existance of a stack overrun condition similar to the one
in Linux in the Solaris ld.so, I do not believe this to be the case.

The bug the program you posted triggers is indeed becasue of a call to
strcpy(), however the buffers in question are not on the stack but are
malloc()ed during run time.  (There are some cases where ld.so first calls
strlen() to determine how much memory to ask malloc() for, if I remember
correctly; obviously, the particular instance you've discovered is not one
of those).

It's been a long while since I disassembled Solaris ld.so, but I don't
think you could do anything useful with these strcpy()s -- the order in
which they are allocated doesn't give you much to work on.

I would not bet my life on it, but I do not remember *any* eye popping
stack overrun conditions in the dynamic loader.

(This does not go to say that there may not be security problems in the
Solaris ld.so -- that is something I would never say about any program --
but the specific bug you posted is benign, IMHO.)




                                                adam?

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