[exim-dev] External barriers to privilege escalation

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: W B Hacker
Data:  
Para: exim-dev
Assunto: [exim-dev] External barriers to privilege escalation
Folks,

In an earlier reply to the initial activity in re remote root exploits, I
indicated that I would research (only) external barriers to limit or prevent
that. Am so doing with 4.69-3 on FreeBSD, and 4.72-1 on OpenBSD

My view is that so long as Exim *ever* has 'root', the best coding on Earth can
be bypassed 'somehow'. The same is true for the steps taken below IF an attacker
gains 'root'.

But at least they make it harder to do from where Exim sits, and they do it 'NOW'.

Here's an update on steps tested to date:

(CAVEAT some of this should work for 'all hands', flagged ALL, some clearly
cannot, flagged SOME).

==

- SOME: /usr/local/sbin/exim-<version major>-<version minor> is no longer setuid
root. Or anything else. For the moment, mode is simply 750

The goal is that even if/as/when Exim is started by root (the normal case on
reboot et al), to allow binding to the privileged ports, any re-exec of the
binary by the then-running master/listener dispatcher/spawner eximd instance
will no longer have the ability to escalate back to root.

TO COMPLETE: Change /usr/local/sbin/exim to setuid <exim_daemon>:<exim_group>.
AWAITS: Time to sort out xinetd and systrace so Exim itself will not NEED root,
even for port binding.

CAVEAT: not being able to/needing to switch EUID:EGID for deliveries depends on:

a) effective use of group privs,

b) and/or not allowing shell account holders to HAVE email. Here, they
(including 'postmaster@') use system-independent ID's as virtual users like
everyone else.

==

- ALL? Per OpenBSD practice, the production FreeBSD boxen now mount /var, and
/<the mailstore> as noexec, nosuid.

I'd call that one an 'ALL' until someone points out what it harms, and WHY that
critter is allowed to <whatever>...

==

- SOME: specify, in /etc/rc.conf exim_flags // /etc/rc.local script the
'specific' ~/etc/exim/configure rather than accept default. Coupled with
restriction of whom may call the raw binary, and/or replacing it with a snippet
of script that ALSO specs said ~/configure, then calls a now-elsewhere/elsenamed
binary, of course. Makes Exim less dependent on internal options.

==

- SOME: (At least) on the *BSD's ~/configure ownership was root:wheel and 644.
It has now been changed to: root:<exim_group> and 640. That so as to not depend
on Exim alone to hide sensitive contents, such as DB login sequence, UID:PWD.

CAVEAT: Only root may directly edit ~/configure. Not new in BSD-land, may not be
so elsewhere, hence the 'SOME'.

==

- TEMPORARY: Have adopted the suggested band-aid of:
     log_selector = ...   -rejected_header


==

TEMPORARY: For the time being, all deny-class verbs in acl_smtp_(p)data have
been converted to 'defer'. I won't even dignify that with a 'SOME', as it is
recent attack-vector specific, and might be mere whistling past the cemetery in
any case. Also obviates the need for the log_selector = -rejected_header. No
rejections with headers to BE logged.

==

Still to vet:

- xinetd or systrace use to hand-off the necessary privileged ports to exim et
al, w/o exim EVER needing root, even for initialization. A 'SOME' at best.

- upping from kern.securelevel of 2 to kern.securelevel of 3 *BSD'ishness?

WANTED:

Yes, I'm professionally paranoid. BUT - also an often over-confident
over-the-hill OF with failed eyesight and failing wet-RAM.

So .. PLEASE shoot holes in the above as appropriate.

Thanks,

Bill Hacker