[ On Tuesday, December 18, 2001 at 23:08:48 (-0500), Theo Schlossnagle wrote: ]
> Subject: Re: [Exim] Exim and IBM DB2
>
> Well, I have studied the research and I have bounced the problems off
> our operating systems guys (here at Johns Hopkins) and most shared the
> sentiment: "Despite the fact that Unix's security model is weak, I trust
> dlopen a hell of a lot more than ld.so -- and EVERYONE uses that".
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.
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.
However dlopen() is permanently available in the running program. New
code can be loaded at any time. That's its purpose after all, but it's
also its downfall when it comes to privileged programs. Leaving a
privileged program free to load new code again at any time after its
execution is very nearly equivalent to a buffer overflow. It makes many
otherwise unexploitable vulnerabilities much easier to exploit (you
probably still have to get the code into the host system's filesystem
namespace, so maybe it isn't always remotely exploitable)....
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.
I wish I had an obvious exploit or exploit technique to show you but as
you can no doubt guess these kinds of vulnerabilities are fundamentally
implementation dependent. All that makes dlopen() unique is that it's
an enabling tool which can be misused as easily as it is used. Do not
use dlopen() and you raise the bar to a level where an attack by this
mechanism is very difficult. Statically link your program and you raise
the bar so high that only a buffer overflow, format string overflow, or
some similar as yet un-discovered technique is the attacker's only hope.
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)
> You have an immense amount of control with dlopen() that you don't have
> when relying on the system's runtime dynamic linker.
You've got it completely backwards -- in most implementations I know of
dlopen() relies on the fact that a process is dynamically linked at
startup as well.
If your references don't like ld.so then they must distrust dlopen() for
privileged programs even more or else they are either contradicting
themselves or misunderstanding the unix process security model.
> It is definitely
> possible to write safe code using dlopen(). Setuid binaries (which exim
> is) have all sorts of extra precautions built into them on all modern
> unicies (e.g. Solaris, Linux, *BSD, Irix)
We're not talking about the setuid binaries themselves, but the process
address space their code lives in after they've been invoked!
> setuid perl is commonly used.
Only by those willing to risk the vulnerabilities it opens you up to....
> I trust Exim not to rely on user environment variables any more than it
> should -- in other words, I trust exim to be "safe."
That's one of the problems. You cannot. Certainly not with anything
even approaching mathematical certainty. Exim is a relatively large
program. Its complexity makes such safety very difficult to prove.
> If I dlopen() some
> object on my system, I expect it to be written in the same way --
> "safe". This isn't really even compromising security for convenience --
> because it is just as safe as the system dynamic linker (and ~0% of
> people statically compile Exim).
Ah, but you see there comes a point where you, the programmer, have no
control whatsoever over what code you load and run. That's where the
problems with plugins begin.
The unix process security model depends _entirely_ on the fact that new
code cannot be loaded into a privileged program after it has begun to
run. I cannot repeat this too many times -- it's a fundamental basic
fact of the overall unix security model.
Another problem is that with dlopen() the programmer must be trusted to
have taken into account all the subtle and important rules that MUST be
obeyed when writing code that runs in a privileged mode. At least with
ld.so this is one very well known program that many people have examined
and tested very carefully -- after all the entire security of a given
system often depends on the safety of this one most important program.
When it comes to writing secure code you must learn to do one thing
right and do it only once in a way it can be reused -- don't try to do
it over and over and over again in a different way each time, and to
require each programmer to deal with all of the details all of the
time. Security is a matter of attention to details, ever so much more
when it comes to computers which have so many details to attend to.
People, even programmers, can only deal with so many details at a time.
> I trust Philip would research the pros and cons of this technique and
> make a judgement call. I also trust that excellent documentation would
> written _clearly_ highlighting any of the pit falls. These are the
> things I have come to rely on from Philip and Exim -- and that is why I
> use 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.)
--
Greg A. Woods
+1 416 218-0098; <gwoods@???>; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
