Re: Shared library annoyance with gcc-3_0-branch

[Alexandre Oliva <aoliva at redhat dot com>]

On Feb 21, 2001, Fergus Henderson <fjh@cs.mu.oz.au> wrote:

> Hmm... this is such an ugly hack, I feel embarrassed to say it...
> but how about using putenv() to communicate the address of the
> static data between the different copies?  Would that work?

I suppose it would work, and I even thought it was an excellent idea
until I considered the security implications of it.

If you're able to predict the PID of the next process you're going to
start, you'd be able to set __LIBGCC_addr__ to an arbitrary memory
address.  In generally, all you'd be able to do is to get the program
to crash.  However, if you manage to find the MAGIC_NUMBER in some
location of the program memory, you might be able to take over control
of the program.  I.e., one more source of security problems similar to
the existing buffer overrun problems that plague bugtraq.

All you have to do is to arrange for some of the program input to
contain the MAGIC_NUMBER and some exploit code, find out the memory
location in which the program will store them, and wait until some
exception is thrown.

Much harder to exploit, I agree, but it still scares the hell out of
me.

Of course, we (or the system loader) could clear these environment
variables on program start-up, but this wouldn't help dlopened shared
libraries.


I'm wondering...  Doesn't the C++ ABI specification determine how EH
should be implemented?  Doesn't its description (assuming there is
one) offer any insights into dealing with this problem?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me