Re: [Exim] Exim and IBM DB2

On Wednesday 19 Dec 2001 8:11 am, you wrote:

> 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)....
>

Yes new code can be loaded at any time, as apoosed to just init time.
Which mean YES you do re-introduce all the same risks that the
programmers of ld.so had to face to the programmers (programmer) of
exim.

Yes Exim is a big program and thus it is next to imposible if not
imposible to "prove" that it is secure but I think it is this very
fact that changes the dicussion from one of fact and principle to
that of personal opinion. I say that because people use exim despite
the privledges that it has because they trust the programmer to do
the right things. The fact that they trust it doesn't make it secure.
Some people may trust the programmer to add a new rdmbs query module,
other may trust the programmer to add a new transport protocol. At
any of these stages a new security whole could be introduced that
would allow new code to be loaded into the running executable (i.e. a
buffer overflow weakness). At any of the stages a new security whole
could be added that enables function of the existing code to be
missused to manipulate files on the target system (The most famous
example is probabaly sendmail debug mode), no new code added but just
a serious a security whole.
The point is I think your fears in weakness in new code in exim that
uses dlopen are valid BUT at the end of the day only personal
judgement can be used to decide if the extra risk is outwayed by the
extra functionality it provides. Its a risk/cost assestment issue,
everyone will come to their conclusions based on their own
requirements. I think your only concern should be that exim does not
compile in such code by default and that users are informed of all
known protential risks (and told this is the KNOWN potential risks).

> 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.

They relie on a more than just that *8-).

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.

Yes, or to trick it to changes files, start new programs, ... You
have to be equaly carefully when using exec !


>
> 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.
>

I agree any program that uses dlopen faces the same risks and
responsabilities that ld.so does.

> > 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!

I think the point was that if a programmer can write safe code to be
used as set uid then write safe code to use dlopen. I disagree with
that assertion to be honest. Firstly it is known that righting safe
setuid code is VERY difficult. You usually can't prove that any
previous work is safe. Two even if previous work is safe new work may
not be. Three dlopen has its own set of security related problems not
all of which overlap with the set of problems faced by setuid
programs.

>
> > setuid perl is commonly used.
>
> Only by those willing to risk the vulnerabilities it opens you up
> to....
>

Which is the point of the whole discussion people are often willing
to take such risks even though they are indeed fully aware of the
risks. Usually in situations where they are dammed if they do and
dammed if they don't *8-)

> > 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.

He said he "trusted" it. Trust is not the same a Knowing. Trust
implies an acceptance of risk. He "trusts" exim to do the right thigs
even with so many lines of code, that is why he is wiling to trust
it with a few more *8-) Still it only take one error on one line
(re-writen or new) ! Get an acutary to do a risk assesment on it *8-)

>
> > 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.

I think he intended to configure exim with an approved list of
plugins by file name. Files that he him self created and maintained.

>
> 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.

This is true and maybe Philip should use the ld.so source and
development notes for a version with a code secureity history as a
source of information for his own limited implementation of dynamic
modules. He has done similar things in the past with writing code
that runs under a setuid execution.

>
>
> 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 --

It supports pipes, it does so safely by throwing away privledges, why
not apply this approach to plugin code. It also supprts embeded perl,
I haven't looked at that yet though. Why should it not offer plugins
and a build time option ?

> 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.

O.K. as long as you have compiled in the stubs to exim, what if you
have a new library ? This guy wants to add a new library to 50
machines without have to reinstall exim 50 times.

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.)


Plugins are needed when the application wishes to prived the ability
to extend it with new functionality in advance of know what the new
functionaly is ! Which is exactly what this guy want's to do and is
exactly why it is so insecure ! A universal plugin API has the
advantage that 3rd parties can develope for exim withought have to
get their new modules api added to the exim source code first before
peple can use it. If you want things to be secure then don't compile
his feature in. If you want things to be securer for people who do
use it I suggest you post some links to references on implmenting
systems that support dynamic or mobile code in a secure fashion.

--Sean