It was reported that acpid version shipped in Red Hat Enterprise Linux 5 (1.0.4) creates its log file (/var/log/acpid) with incorrect permissions, on some platforms, even with random permissions. Original report: https://bugzilla.redhat.com/show_bug.cgi?id=515062 Problem was caused by the missing 3rd argument to open() when called with O_CREAT flag. As a result, log file may end up being world writeable and with setuid / setgid bit set, possibly allowing privilege escalation. This issue does not affect current acpid versions (1.0.6 and later), as they use syslog() logging.
This problem is not reproducible on Red Hat Enterprise Linux 4 (acpid 1.0.3) and Red Hat Enterprise Linux 3 (acpid 1.0.2), log is always created with 640 permissions. Checking the differences between 1.0.3 and 1.0.4, 1.0.3 does this in the open_logs() function: 413 nullfd = open("/dev/null", O_RDONLY, 0640); 414 if (nullfd < 0) { ... 418 } 419 logfd = open(logfile, O_WRONLY|O_CREAT|O_APPEND); While 1.0.4 no longer passes mode to the first open call (where it's ignore, but it also causes second open to see that mode too): 429 nullfd = open("/dev/null", O_RDONLY); 430 if (nullfd < 0) { ... 434 } 435 logfd = open(logfile, O_WRONLY|O_CREAT|O_APPEND);
Marc Deslauriers pointed out that missing mode argument in /dev/null open call is not from upstream 1.0.4 source, but rather a change from Red Hat patch acpid-1.0.4-fd.patch. That patch was introduced in Red Hat Enterprise Linux 5.3 update package acpid-1.0.4-7.el5: https://rhn.redhat.com/errata/RHBA-2009-0091.html Log files created by previous version of acpid does not get random permissions.
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2009:1642 https://rhn.redhat.com/errata/RHSA-2009-1642.html
The trigger in the updated package is broken: triggerin scriptlet (using /bin/sh) -- acpid <= 1.0.4-9.el5_4.1 [ -f /var/log/acpid ] && chmod 0644 /var/log/acpid* If acpid is installed but never ran, /var/log/acpid does not exist, the trigger fails, the transaction is aborted, the system is left with two instances of acpid, ...
Hi Stephan, thank you for reporting this deficiency to us. Could you please open a new Red Hat Bugzilla entry for this acpid problem in Red Hat Enterprise Linux 5 against 5.5 version, so it could be addressed there? Please note, this Bugzilla record is dedicated only for the acpid CVE-2009-4033 security issue (assuming the above mentioned problem was present also in versions of acpid package prior to 1.0.4-9.el5_4.1). Thanks, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team
Common Vulnerabilities and Exposures also assigned an identifier CVE-2009-4235 to the following acpid vulnerability: acpid 1.0.4 sets an unrestrictive umask, which might allow local users to leverage weak permissions on /var/log/acpid, and obtain sensitive information by reading this file or cause a denial of service by overwriting this file, a different vulnerability than CVE-2009-4033. References: ----------- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4235 https://bugzilla.redhat.com/show_bug.cgi?id=515062 https://bugzilla.redhat.com/show_bug.cgi?id=542926 http://www.redhat.com/support/errata/RHSA-2009-1642.html http://securitytracker.com/id?1023284
Hi Jan, sorry. The new bug is #545760. Regards, Stephan
(In reply to comment #8) > Common Vulnerabilities and Exposures also assigned an identifier CVE-2009-4235 > to the following acpid vulnerability: > > acpid 1.0.4 sets an unrestrictive umask, which might allow local users > to leverage weak permissions on /var/log/acpid, and obtain sensitive > information by reading this file or cause a denial of service by > overwriting this file, a different vulnerability than CVE-2009-4033. It seems that this extra CVE was assigned based on the following comment: https://bugzilla.redhat.com/show_bug.cgi?id=515062#c8 However, the mentioned umask(0) does not need to be called a separate security issue, IMO. The real problem here was a missing mode argument to open() call with O_CREAT. More restrictive umask could have prevented it, but it's not required to fix it. If sane mode is passed to open(), umask set by a calling process can only make file permissions more restrictive. As noted in comment #1, umask(0) was not a problem in versions without acpid-1.0.4-fd.patch patch, as mode 0640 from previous open() call was "re-used", resulting in safe file permissions. Therefore, I view CVE-2009-4235 as duplicate of CVE-2009-4033, rather than a different issue.