Recently modified vulnerabilities for "sa-exim" 4.69

Where

AND

Sort:

redhat/eximFormat string vulnerability in the dkim_exim_verify_finish function in src/dkim.c in Exim before 4.7…

Risk 53

Severity

7.5

AV:N/AC:L/Au:N/C:P/I:P/A:P

Format string vulnerability in the dkimeximverifyfinish function in src/dkim.c in Exim before 4.76 might allow remote attackers to execute arbitrary code or cause a denial of service (daemon crash) via format string specifiers in data used in DKIM logging, as demonstrated by an identity field containing a % (percent) character.

1 / 2

Source: MITRE

First published (updated )

CVE-2011-1764

Exim EximInput Validation

Risk 59

Severity

6.9

Input Validation

AV:L/AC:M/Au:N/C:C/I:C/A:C

The openlog function in log.c in Exim 4.72 and earlier does not check the return value from (1) setuid or (2) setgid system calls, which allows local users to append log data to arbitrary files via a symlink attack.

First published (updated )

CVE-2011-0017

Exim EximInput Validation

Risk 47

Severity

6.8

Input Validation

AV:N/AC:M/Au:N/C:P/I:P/A:P

The dmarcprocess function in dmarc.c in Exim before 4.82.1, when EXPERIMENTALDMARC is enabled, allows remote attackers to execute arbitrary code via the From header in an email, which is passed to the expandstring function.

First published (updated )

CVE-2014-2957

redhat/eximexpand.c in Exim before 4.83 expands mathematical comparisons twice, which allows local users to gai…

Risk 36

Severity

4.6

AV:L/AC:L/Au:N/C:P/I:P/A:P

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-483:/doc/doc-txt/ChangeLog [3] http://git.exim.org/exim.git/commitdiff/7685ce68148a083d7759e78d01aa5198fc099c44 [4] http://git.exim.org/exim.git/commitdiff/0de7239e563eff6e83c3e72d7deb9fd26a54a3a7

1 / 2

Source: Red Hat

First published (updated )

CVE-2014-2972