Re: [exim-dev] Security of ${dlfunc

David Woodhouse wrote:
> On Wed, 2010-12-15 at 08:10 -0500, W B Hacker wrote:
>>
>> At the very least, these over-helpful critters and their kin should be
>> pulled
>> back to non-default compile time options. And their hazards made VERY
>> clear.
>
> I disagree.
>
> Firstly, the flexibility you're talking about is what makes Exim what it
> is.

(Part of) my point is that we DO NOT lose any significant flexibility.

WTH - I can have an SQL INSERT run from *anywhere* in Exim's configure
From which - a PostgreSQL/Ingres 'trigger' can do *anything*. Not all that
different with a much simpler text file, (that is, or can be made to be,
executable) as you point out (below).

But abuse or 'feature' - such shenanigans - and protecting THEM from abuse -
remain on MY 'local admin' shoulders entirely.

In each case, something or several somethings, *external to Exim* must be
compromised as well.

> If I wanted a crippled MTA that couldn't do half the things I
> currently do with Exim, then I'd be using Postfix.

With adequate investment of time and and coding skills, Postfix can be made to
do most of what Exim does also. IBM didn't need those when they fed and housed
Weitse and a co-worker to develop Postfix, ELSE it might have had them.

With far less investment, 'coz Sam is both RFC-strict AND paranoid, the parts of
the quite flexible courier-mta 'suite' can do.

Exim's utility isn't that other MTA 'can never' but that Exim can do more
'stuff, do it easily, quickly, NOW, and w/o coding in C or C++.

I don't propose that this go away.

Only that it be far more tightly coupled to whatever a legitimate
installer/admin chooses to do - and may have to work a bit harder at, yes.

But primarily from the standpoint of paying closer attention to paths, privs,
group memberships and fs structures - not missing tools in Exim.

Just fewer and more careful entrances to those tools.

AND the deliberate choice to build with them. Or not.

After all, *SQL tools were/are not built by default.

An SQL-Lite or MySQL maven might not realize how much power is in those hands.

A DB2, Oracle, or PostgreSQL guru with 'triggers' or stored-procedures in his
arsenal, DOES do.

>
> And secondly, the problem here is *not* the features. The problem here
> is that we allowed its behaviour, when running as root, to be controlled
> by a user that was not root and should not have been trusted. It was a
> fault in the privilege separation design, pure and simple.
>

Yes, and again YES. I *want* all that. It is all good stuff. The effort is
valuable, professional, most welcome. Not wasted.

But I *also* want an understanding that 'we' have been perhaps luckier than not
that these tools have not (so far as is known) been more widely abused.

A bit less trust and belief in the goodness of our fellow man, if you will.
If it can BE exploited, some bastard will do so.

Let's make sure he/she has to compromise more than just an Exim 'feature' to
succeed.

Exim has become too widely deployed to rely on ignorance. The bar has been raised.

> Even if we lost all the features which actually make Exim worthwhile,
> and all it could do was append to a text file, that could still be
> abused if the privilege separation isn't working right.
>
> I think our direction at the moment, fixing the privilege separation
> issues and allowing for only *certain* variations which are "blessed" in
> advance by the root user, is the correct one.
>

I hope so.

Mind - I know this un-requested extra measure of paranoia is not welcome.

But it just might long-term repay the short-term distracting influence it
constitutes ... if those who DO code would be a bit more suspicious to insure
that their elegant and workable solutions are ALSO pragmatically 'unbreakable'
ones.

Globally. Not just locally.

Regards,

Bill