Bug 661756 (CVE-2010-4344)

Summary: CVE-2010-4344 exim remote code execution flaw
Product: [Other] Security Response Reporter: Josh Bressers <bressers>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: urgent Docs Contact:
Priority: urgent    
Version: unspecifiedCC: agk, dwalsh, dwmw2, jlieskov, jmorris, jp, levon, luke, mjc, mlichvar, nixon, rcvalle, ruben, wnefal+redhatbugzilla
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: public=20101207,reported=20101209,source=internet,impact=critical,rhel-4/exim=affected,fedora-all/exim=affected,rhel-5/exim=affected,rhel-5.3.z/exim=affected,rhel-5.4.z/exim=affected,rhel-4.7.z/exim=affected,cvss2=7.5/AV:N/AC:L/Au:N/C:P/I:P/A:P,cwe=CWE-78
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-13 06:59:20 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 662019, 662020, 662021, 662022, 662023, 662024, 662030    
Bug Blocks:    

Description Josh Bressers 2010-12-09 10:45:35 EST
There is a possible remote root flaw in Exim:
http://www.exim.org/lurker/message/20101207.215955.bb32d4f2.en.html

We do not currently know more than is contained in this mail. We will
update this bug with further information as it is discovered.
Comment 3 David Woodhouse 2010-12-09 13:50:31 EST
There are two bugs here. First a remote exploit where the attacker somehow tricks Exim into evaluating data it shouldn't, and honouring a ${run {/bin/sh...}} directive which ends up giving the attacker a shell.

Secondly a privilege escalation where the trusted 'exim' user is able to tell Exim to use arbitrary config files, in which further ${run ...} commands will be invoked as root.

The latter should be addressed by the patch at http://lists.exim.org/lurker/message/20101209.172233.abcba158.en.html

The former we still haven't managed to reproduce, but we suspect an issue with Exim's POOL_MAIN data store, which works a bit like a stack. When the first message is received, we store data about it on this 'stack', and when it's rejected for being too big, the stack pointer gets reset. And then when the attacker attempts to deliver a second mail over the same connection, they somehow manage to trick Exim into evaluating the strings they put on the stack the first time round.

I've added Valgrind instrumentation to mark the data in the pool as undefined when the pool is reset, but it's not triggering... but then I'm not actually seeing the exploit work either. I'm fairly sure that using memset to zero the pool when it's reset would be a cheap 'fix' for this, but I really want to find the real bug where we're using uninitialised data, be sure that's really what it is, and fix the real problem rather than working around it.
Comment 7 Mark J. Cox (Product Security) 2010-12-10 04:49:24 EST
CVE-2010-4344 exim vuln that allows remote code execution as 'exim'
CVE-2010-4345 exim vuln that allows privilege escalation 'exim' to root
Comment 10 Mark J. Cox (Product Security) 2010-12-10 05:40:32 EST
Split privilege escalation part, CVE-2010-4345, into bug #662012
Comment 11 Mark J. Cox (Product Security) 2010-12-10 05:43:57 EST
CVSSv2 for CVE-2010-4344: 7.5/AV:N/AC:L/Au:N/C:P/I:P/A:P
CVSSv2 for CVE-2010-4345: 6.8/AV:L/AC:L/Au:S/C:C/I:C/A:C
(CVSSv2 for both combined 10.0/AV:N/AC:L/Au:N/C:C/I:C/A:C )
Comment 12 Miroslav Lichvar 2010-12-10 06:01:58 EST
*** Bug 662013 has been marked as a duplicate of this bug. ***
Comment 18 David Woodhouse 2010-12-10 08:53:51 EST
This is Exim bug 787, fixed by http://git.exim.org/exim.git/commitdiff/24c929a2 in Exim 4.70.

An immediate workaround for the specific exploit that's been seen in the wild would be to disable the logging of headers of rejected messages, by setting 'log_selector = -rejected_header' in the configuration file. Of course, this was a generic bug in the string handling so it's not entirely impossible that there could be another way to exploit it.
Comment 19 Tomas Hoger 2010-12-10 09:02:37 EST
(In reply to comment #18)
> This is Exim bug 787

http://bugs.exim.org/show_bug.cgi?id=787
Comment 20 Tomas Hoger 2010-12-10 12:54:14 EST
David Woodhouse's mail on exim-dev with additional details and current upstream status of both issues:

http://lists.exim.org/lurker/message/20101210.164935.385e04d0.en.html
Comment 22 errata-xmlrpc 2010-12-10 16:48:14 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4
  Red Hat Enterprise Linux 5
  Red Hat Enterprise Linux 5.3.Z - Server Only
  Red Hat Enterprise Linux 5.4.Z - Server Only
  Red Hat Enterprise Linux 4.7 Z Stream

Via RHSA-2010:0970 https://rhn.redhat.com/errata/RHSA-2010-0970.html