Bug 661756 (CVE-2010-4344)
| Summary: | CVE-2010-4344 exim: remote code execution flaw | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Josh Bressers <bressers> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | unspecified | CC: | 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: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-12-13 11:59:20 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 662019, 662020, 662021, 662022, 662023, 662024, 662030 | ||
| Bug Blocks: | |||
|
Description
Josh Bressers
2010-12-09 15:45:35 UTC
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.
CVE-2010-4344 exim vuln that allows remote code execution as 'exim' CVE-2010-4345 exim vuln that allows privilege escalation 'exim' to root Split privilege escalation part, CVE-2010-4345, into bug #662012 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 ) *** Bug 662013 has been marked as a duplicate of this bug. *** 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. (In reply to comment #18) > This is Exim bug 787 http://bugs.exim.org/show_bug.cgi?id=787 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 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 |