Re: [Exim] Exim and IBM DB2

On Wednesday, December 19, 2001, at 03:11 AM, Greg A. Woods wrote:
> That suggests your references really do not understand the unix process
> security model. It's really not that hard to understand, though people
> have been making fatal mistakes in doing so for decades now, so I guess
> it shouldn't surprise me too much any more.

I won't bother addressing those comments. Check your references.

> ld.so does it's work before the program gets control -- certainly you
> depend on its security checks not to allow an attacker to thwart it into
> loading libraries that should not be trusted in cases where such trust
> is important (eg. when the program is setuid). ld.so is never run again
> after the program counter jumps to the main program's entry point.

So, if ld.so makes a mistake, your screwed. If dlopen() is called and
you see that any things is suspect, you exit before anything bad
happens. You have no risk (if you code it right) of any code just
"executing" when you call dlopen()). _init would run, if you were so
careless to dlopen() an object with _init in it. So, don't.

> You see the problem is that the unix process security model depends
> _entirely_ on the fact that privileged programs are not ever supposed to
> be able to load new code after they're started. That's why buffer
> overflows are suddenly big news -- they allow an attacker a way to
> introduce foreign code into a process (and of course give them an avenue
> to trigger it). dlopen() does the same and all that's left is for the
> attacker to find a way to trick the program into loading the wrong code.

So much clearer! Thank you. I completely agree with you. But, you
stance is different from mine. If someone can buffer overflow Exim
there is a security problem. If someone can convince dlopen() to load
the wrong code, it is a security problem. Address the problems, don't
avoid using techniques because current supporting implementations are
flawed -- they can be fixed. That is a good approach to make no new
advances.

> Besides not everyone uses ld.so. I've got a couple of systems now where
> no process running with root privileges is dynamically linked. I.e. the
> entire system is statically linked, even all of the X11 client programs
> (and of course the X11 server too). They work very well, thank you!
> (ld.so still exists, as do the system shared libraries, but only so that
> end users can build and run dynamically linked programs)

I said ~0% use static linking. I use static linking all the time too.
It is just silly for things like Exim. It uses openssl and libdb and
openldap... All my other programs do too. What a waste of system
resources. There are times and places for static linking -- and it is
always an option for the paranoid. I have nothing against it.

> What's really stupid about this whole idea is that a program like exim
> need never ever in a million zillion years load plugin code -- they can
> far more effectively and simply use a plain old shared library instead,
> even if it were a proprietary binary. The code never need be unloaded
> and it never need be replaced so it can be pre-linked, or linked at run
> time by ld.so, just as well. Plugin techniques are only just barely
> necessary for some kinds of implementations of exceedingly complex and
> dynamic application programs, and they're so often misused that they
> most often turn into stupid lame excuses to use cool-sounding technology
> for no reason whatsoever. (Personally I find more powerful embedded
> extension languages to be far preferrable to loading binary plugin
> code.)

Perl embedding suffers from ALL of the same problems, because the perl
interpreter brings -ldl with it.

--
Theo Schlossnagle
1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7