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

Ted Cooper wrote:
> On 13/12/10 23:02, Tony Finch wrote:
>> ${dlfunc is not included in the default build. If it is included then
>> anyone who can modify the configuration file can insert arbitrary code
>> into Exim, since ${dlfunc includes the filename of the shared object to be
>> loaded. IIRC when developing the feature I thought this was OK since it's
>> roughly as dangerous as ${run. Clearly this isn't in fact OK.
>>
>> I propose to change the feature to allow the shared object to be specified
>> at compile time instead of run time. This has the advantage of making the
>> configuration syntax less cluttered. For compatibility I'll allow a set of
>> acceptable shared object parent directories to be compiled in, so if a
>> filename is specified in ${dlfunc then it can be checked for safety.
>> The idea is similar logic to David's config file safety work.
>>
>> PS. sorry for my lack of contributions last week. I couldn't keep up with
>> the rest of you so never had anything to add!
>
> I thought the point of dlfunc was to allow for code to be included in
> Exim that wasn't compiled in to start with.

Mark that thought.

> ie If you were using Debian
> 4.69 light and wanted some special piece of code to do do whatzit, you
> just dlfunc include some code and voila, all done. If the binary has to
> be recompiled, it somewhat defeats the whole purpose of it.
>
> The changes to the allowed config file and when root priv is being
> dropped should be enough to protect ${run} and by the comparison in your
> post, ${dlfunc}
>
>

Folks,

From the grey-haired seats, please. Please. Step a pace or three back and take
a hard look at what is afoot here.

Has it come about, in the quest to make Exim ever-more flexible, that a monster
was born? One now being merely 'trained' a bit?

- with -C and -D we permit a running instance to modify its entire set of
sailing orders. Even - as ONE recent exploit demonstrates, to not being itself
at all, but to execute some unrelated, arbitrary, and dangerous behaviour..

- with ${dlfunc Exim is helped to extend/alter even the 'functionality' of its
binary.

All the regex, priv's-checking, and dirtree vetting that can now be plastered-on
is mere treatment of the symptoms. Locks on virtual 'backdoors' as it were.

Short take?

- A) The -C, -D, ${dlfunc capabilities are simply 'too much' flexibility for
server-land. Protecting them borders on the impossible.

- B) They are almost certainly not even necessary in 99.99% + of all installations.

Why so?

Because the 'one and only' legitimate, vetted, 'protected' by fs-location &
privs, chosen-by-root-at-startup ~/configure...

... can suck-in all manner of branching and behavioural modification thingies
*ANYWAY*! And 'on the fly'.

Lookups, lists, and MACRO-fillers from everything readable, from flat-files to
complex 'heavy lifter' SQL DB's, local ... or remote.

That flexibility is not readily amenable to bullet-proofing, *either*.

But at least channelizing to that-chosen-one-only ~/configure places the onus
entirely on whomever crafted the custom ~/configure file and its sputniks in the
first instance:

The 'porter's, local installers, sysdamins.

Not on the devels.

IMNSHO, the crafting of suicide kits is not in Exim devel team's brief.

Not even as a byproduct of helpfulness.

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.

'pain'? Some. But going forward? 'redemption' as well.

That reported security breach was not theorectical.

And may not have been alone.

Let's get the 'big rocks' into the jar first.

Bill