Bug 542926 (CVE-2009-4033, CVE-2009-4235) - CVE-2009-4033 acpid: log file created with random permissions
Summary: CVE-2009-4033 acpid: log file created with random permissions
Status: CLOSED ERRATA
Alias: CVE-2009-4033, CVE-2009-4235
Product: Security Response
Classification: Other
Component: vulnerability   
(Show other bugs)
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=important,source=secalert,repo...
Keywords: Security
Depends On: 515062 542928
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-12-01 08:47 UTC by Tomas Hoger
Modified: 2009-12-15 12:11 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 545760 (view as bug list)
Environment:
Last Closed: 2009-12-15 12:11:21 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1642 normal SHIPPED_LIVE Important: acpid security update 2009-12-07 17:11:14 UTC

Description Tomas Hoger 2009-12-01 08:47:55 UTC
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.

Comment 1 Tomas Hoger 2009-12-01 08:53:08 UTC
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);

Comment 4 Tomas Hoger 2009-12-01 15:02:52 UTC
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.

Comment 5 errata-xmlrpc 2009-12-07 17:11:17 UTC
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

Comment 6 Stephan Wiesand 2009-12-09 08:28:45 UTC
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, ...

Comment 7 Jan Lieskovsky 2009-12-09 09:53:17 UTC
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

Comment 8 Jan Lieskovsky 2009-12-09 10:17:05 UTC
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

Comment 9 Stephan Wiesand 2009-12-09 10:25:31 UTC
Hi Jan,

sorry. The new bug is #545760.

Regards,
  Stephan

Comment 10 Tomas Hoger 2009-12-15 12:11:21 UTC
(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.


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