Re: [exim-dev] Remote root vulnerability in Exim

On 08/12/10 07:59, Sergey Kononenko wrote:
> Hi,
>
> While investigating security break in the network of my company, I've
> captured (by tcpdump) sequence of successful remote root attack through
> Exim. It was Exim from Debian Lenny (exim4-daemon-light 4.69-9). I
> didn't find email of current maintainer of Exim, so I've decided to
> write to this mailing lists. I don't want to publish all details of
> attack before developers can investigate and fix vulnerability.
> So I ask Exim maintainers to contact me and I will send them complete
> captured sequence of attack.
> Here I can put brief sequence of attack:

I've had a quick look at this and so far the issue is certainly real enough.

The exim -> root escalation is because the exim user is priviledged in
exim and can use -C command line opt along with setuid bit set on exim
binary. No other users normally have this but it can be configure to
allow it.

eg with normal user
$ exim -Ce.conf -q
exim: permission denied

Mitigation to prevent root upgrade can be to remove the setuid bit if
you don't do local deliveries, use the command line "sendmail" interface
or anything else that needs it.

Better mitigation is to recompile exim with ALT_CONFIG_PREFIX set to
somewhere that the exim user cannot write to (/etc/exim?), or set
ALT_CONFIG_ROOT_ONLY=yes if you don't use -C for anything special. Same
with DISABLE_D_OPTION.

Addressing the special user exim being able to run anything they want is
a possible issue we should discuss but I can't see an easy way to
prevent this. It's somewhat crucial to how exim works and can be
mitigated by the step above. Perhaps we should default to having these
enabled.

The real issue here is why Exim is treating the HeaderX line like
trusted configuration data. There must be a buffer overflow but I
haven't spotted it in the few minutes I've looked at this. I can
probably find it without the data dump but if someone else can put some
eyes on this too that would be great. I'm not that good at spotting
things like this but no-one else has said anything.

Are there code differences between debian 4.69-9 and normal 4.69? I'm
doing my checking on 4.72.