Author: W B Hacker Date: To: Ted Cooper CC: exim-dev, David Woodhouse, Phil Pennock, Philip Hazel Subject: 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.
