CVE-2011-0017 - check return value of setuid/setgid. This is a
privilege escalation vulnerability whereby the Exim run-time user
can cause root to append content of the attacker's choosing to
(In reply to comment #0)
> CVE-2011-0017 - check return value of setuid/setgid. This is a
> privilege escalation vulnerability whereby the Exim run-time user
> can cause root to append content of the attacker's choosing to
> arbitrary files.
> Reproducible: Always
Thanks for the report, Keath.
4.74 in the tree now, thanks
Excellent. Arches, please stabilize =mail-mta/exim-4.74
Created attachment 261222 [details]
fails for me
(In reply to comment #4)
> Created an attachment (id=261222) [details]
> Build log
> fails for me
Yeah, that's very funny pkg and for me that's ^^ 4th unique failure. I've also hit bug 287426, bug 352265 and as-needed failure with USE="sqlite". Apparently these are not regressions, so we could stable it. However, I'd rather see this package fixed (at least linking issues with dl and improper use of LDFLAGS) before stabilization or pmasked and dropped.
Dropping exim is not an option, so suggesting that shows little to no respect IMO.
Please open up bug(s) for your compilation problems, so we don't pollute this security bug with all of this.
Stable for HPPA.
I tested =mail-mta/exim-4.74-r1 on x86 and this one looks really good to go for me.
The only thing left that would be nice, would be that exim-acl should get auto-enabled if spf and/or srs is enabled, instead of just dying. (I just stumbled upon the last comment from Thomas Kahle over at bug #343221 a few mionutes ago! ;-)
stable x86, thanks Andreas
Stable on alpha.
amd64 done. Thanks Agostino
Thanks, everyone. Added to existing GLSA request.
all versions <4.74 have been dropped from the tree
@security: please close this bug
The open_log 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.
This issue was resolved and addressed in
GLSA 201401-32 at http://security.gentoo.org/glsa/glsa-201401-32.xml
by GLSA coordinator Mikle Kolyada (Zlogene).