[ On Saturday, December 15, 2001 at 18:49:20 (-0500), Theo Schlossnagle wrote: ]
> Subject: Re: [Exim] Exim and IBM DB2
>
> On Saturday, December 15, 2001, at 12:54 AM, Greg A. Woods wrote:
> > Perhaps you do not understand the fundamentals of Unix process security.
>
> I think I have a pretty good grasp.
>
> (1) It is simple to ensure that a process loads the binary shared object
> that you intend.
> (2) It is also just as simple to ensure that that object (file) does not
> get modified as it is to ensure that the binary executable itself is not
> modified.
>
> If you do not know how to do these two things, then reading
> documentation might help.
The first part of your so-called solution is nowhere near as simple as
you make it out to be. There are many variables you don't seem to be
taking into account.
> The Unix process security model has deficiencies as does dynamic
> loading, but they are orthogonal and not impact each other if coded
> correctly.
No I'm afraid you're very wrong there. Dynamic laoding compounds the
deficiencies in the Unix process security model, especially where
privileged processes are involved. Dynamic loading ability is very
nearly like having a ready-made buffer overflow in your program!
Note that I'm not talking about the situation where the program is
dynamically linked on startup by ld.so, but of course where the program
itself uses dlopen() et al. Most of the known, and even most of the
theoretical, bugs in ld.so have been well stomped out. However by
giving the process the ability to dynamically load arbitrary new code at
any time after it has been started you open an entire new can of worms
which have not even been explored in full theoretically yet! However
even the few corners that have been explored suggest there could be many
grave dangers.
Even without directly attacking dlopen() and friends, or the files they
read, their presence gives the attacker using some other exploit the
easy ability to avoid intrusion detection while still running in some
innocent-looking privileged process -- a process that could appear to be
still operating normally at the same time!
> Exim is owned by root (or exim), the configuration file is owned by root
> (or exim) and the shared modules to load would be owned by root (or
> exim). If your code can be subverted to load the wrong module at a
> users whim, then the code is improperly written.
Perhaps you should go out and study how dynamic loading of new object
code is implemented in its various incarnations in Unix and unix-like
systems.
It is not possible to "properly" avoid having undesired code loaded into
a running process that's been given the ability to dynamically load new
object code into itself. The mere ability to load new object code makes
the process vulnerable. Exploiting such an ability is not always
possible, just as exploiting a buffer overflow is not always possible.
However would you include a buffer overflow bug in your code anyway if
you thought it wasn't exploitable?
One of the reasons I fear even normal dynamically linked privileged
executables is that in some implementations they harbour the hidden
ability to dynamically load new object code even if they've not been
explicitly linked with dlopen() and friends. It's only a matter of time
before some attacker figures out how to make use of this ability.
> If you can change the
> contents of those modules, then it follows that the contents of the
> configuration file and the exim binary itself could be modified and you
> have more serious problems [that are out of the scope of this
> discussion].
It's not a matter of changing the disk image contents of any given
modules. That's not the avenue of attack I worry about at all. The
problems with dynamic loading are more with modules introduced by the
attacker, much in the same way that an attacker can use a buffer
overflow bug, or even a printf format string bug, to introduce foreign
code into the running process.
> (1) They were not made out of convenience, but were simply designed with
> convenience in mind.
Such convenience is not necessary -- it is easily attained in other ways
that do not involve dynamic loading of object code. Systems programmers
have been dealing with these very same issues for dozens of years now.
Only a few have wasted their time trying to find ways to maintain the
integrity of programs that can dynamically load new object code.
> (2) If your code can "dynamically load new code at any time" then you
> designed it that way. If you write your code to dynamically load things
> at specific times (immediately after configuration, for example) then
> you shouldn't be concerned with it loading "at any time."
Once again I would _strongly_ suggest you learn the actual details of
how dynamic loading is done in unix environments.
> (3) Those concerned with running dynamically linked code can simply
> compile statically. Those concerned with dynamically loaded modules can
> simply _not use them_.
Of course! Unfortunately as it seems clear from your attitude there are
many people who simply don't understand the real risks and who would
blindly leave themselves open without even understanding why. The key
is to not build in too much rope in the first place, especially not when
doing so leaves it slung over a convenient branch with a ready-made loop!
> Very little is _necessary_. That isn't the point. I have exim
> "patched" up to do all sorts of things. I don't want to integrate those
> changes into the source tree at all becuase the code is proprietary.
Your patches are your own responsibility. You need not publish them in
order to use them in any way you see fit. Since Exim's source is also
freely available and can similary be used in any way you see fit,
there's nothing lost by integrating your private changes into your
private copy of the Exim source. You do not have to publish the result.
You do not even have to admit that you created it. The resulting
collective work does not exist w.r.t. any copyright law until/unless you
attempt to distribute it, but since you consider your part of it to be
proprietary this will never be a problem.
Of course this prevents you from ever distributing the resulting program
under license, but presumably this is not a problem (is it?). (but see
below)
You don't even have to put the main body of your source code on the same
machine you build exim on -- you can just as easily distribute your code
in object form and only introduce it to exim at load time (which might
even mean run-time if you put your code in a dynamically loaded
library). You need only introduce the necessary calls to your code in
the appropriate places in the Exim code.
This latter kind of mechanism should even allow you to distribute your
proprietary code under license -- though for strictest avoidance of the
GPL you'd still have to distribute patches for your hooks into Exim and
require that the licensee apply them to their own legitimate copy of the
Exim sources, in the privacy of their own machine.
> Exim could be coded in assembly -- C isn't _necessary_. Damn
> convenient, don't you think? dynamically loadable modules for hooking
> into different phases of exim processing (logging specifically) either
> requires code modification or dynamically loadable module support. With
> dynamically loadable modules, I don't have to patch every new version of
> Exim as it is released -- only when the API changes.
Hopefully you don't have to learn the hard way of the errors in your
thinking....
If you really don't want to take responsibility for maintaining your own
code and integrating it properly into a wonderful mailer that's been
made freely available in source form, in part just so you can do that
very kind of integration, then I would strongly suggest you go find some
proprietary mailer vendor to work with.
> Again, if you think it is a security concern to use loadable modules,
> then don't configure it to load any -- it couldn't be more simple.
It's not me, or even you in particular, that I'm concerned about. It
would be sad to see a mailer as popular as Exim gain such a dangerous
capability for no real reason whatsoever.
--
Greg A. Woods
+1 416 218-0098; <gwoods@???>; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
