Bug 1122552 (CVE-2014-2972) - CVE-2014-2972 exim: local code execution via string expansion
Summary: CVE-2014-2972 exim: local code execution via string expansion
Alias: CVE-2014-2972
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1122554 1122555
TreeView+ depends on / blocked
Reported: 2014-07-23 13:33 UTC by Vincent Danen
Modified: 2021-02-17 06:21 UTC (History)
4 users (show)

Fixed In Version: exim 4.83
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-08-05 15:17:52 UTC

Attachments (Terms of Use)

Description Vincent Danen 2014-07-23 13:33:16 UTC
As reported to the exim user's mailing list [1], Exim suffers from a local vulnerability where a string expansion is evaluated twice.  If a local attacker were able to provide unsanitized data to a data source used by Exim for looking up a value, in certain situations, the data would be eval()'d twice.  This is not remotely exploitable and requires a user account on the Exim server, and an Exim configuration that does lookups against files to which the user has edit access.  The end result is that, if the conditions are true, arbitrary code could be executed as the exim user.  As described in the posting:

The root cause of this issue is the arguments to mathematical comparison 
operations are expanded twice (<, <=, >, >=, =). The intent of the 
original code was the first expansion could (for example) lookup an item 
from a file. The assumption was that entry would be some form of valid 
integer so that value was then passed to the expand function again to do 
a numeric conversion of values such as 19k or 45M to integers. However, 
if the content of the lookup is under direct user control, they could 
insert something with an expansion, such as: 

${run {/bin/touch /tmp/OUCH}} 

Since the data is not sanitized when the second expansion occurs 
(intended to process numerical conversion), that command would get 
executed as the exim user. 

This is corrected in the Exim 4.83 release [2],[3],[4].  From the description, it looks as though every version of Exim released since 2004 is affected.

[1] https://lists.exim.org/lurker/message/20140722.152452.d6c019e8.en.html
[2] http://git.exim.org/exim.git/blob/exim-4_83:/doc/doc-txt/ChangeLog
[3] http://git.exim.org/exim.git/commitdiff/7685ce68148a083d7759e78d01aa5198fc099c44
[4] http://git.exim.org/exim.git/commitdiff/0de7239e563eff6e83c3e72d7deb9fd26a54a3a7

Comment 1 Vincent Danen 2014-07-23 13:42:43 UTC
Created exim tracking bugs for this issue:

Affects: fedora-all [bug 1122554]
Affects: epel-6 [bug 1122555]

Comment 2 Vincent Danen 2014-07-23 13:50:22 UTC

Red Hat Enterprise Linux 5 is now in Production 3 Phase of the support and maintenance life cycle. This has been rated as having Low security impact and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.

Comment 3 Fedora Update System 2014-08-01 23:55:17 UTC
exim-4.80.1-4.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 4 Fedora Update System 2014-08-01 23:56:47 UTC
exim-4.80.1-7.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.