Bug 435442 - (CVE-2008-0884) CVE-2008-0884 system-auth-ac is world-writable
CVE-2008-0884 system-auth-ac is world-writable
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Steve Grubb
reported=20080228,source=individual,p...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-29 06:53 EST by Mark J. Cox (Product Security)
Modified: 2013-08-22 15:49 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-24 07:11:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mark J. Cox (Product Security) 2008-02-29 06:53:20 EST
The CAPP/LSPP config script causes a world-writable file for both IBM and HP 
certifications
ftp://ftp.redhat.com/pub/redhat/linux/eal/EAL4_RHEL5/IBM/RPMS/lspp-eal4-config-ibm-0.65-1.el5.noarch.rpm
ftp://ftp.redhat.com/pub/redhat/linux/eal/EAL4_RHEL5/HP/RPMS/capp-lspp-eal4-config-hp-0.65-1.el5.noarch.rpm

Detailed report in next comment
Comment 1 Mark J. Cox (Product Security) 2008-02-29 06:55:48 EST
Unfortunately, using the shipped RHEL5 kickstart configuration RPM
results in an insecure configuration, the /etc/pam.d/system-auth file is
set to be world writable.

The potential impact of this is serious, since unauthorized changes to
this file can disable or weaken the system's authentication methods,
including remote access. Authorized users with limited privileges could
exploit this to gain additional access, and it could also be an
escalation method for other vulnerabilities in low-privilege services.

As a mitigating factor, the MLS SELinux policy prohibits write access to
the PAM files for normal users in LSPP mode. In CAPP mode, the targeted
policy does allow write access for normal users. Also, just installing
the RPM does not change any permissions, the capp-lspp-config script
needs to run (normally as part of the kickstart-based installation) to do
so.

The following is a more detailed explanation of the cause and my attempt
to track down the history of the changes resulting in the insecure
configuration - a proposed workaround patch for the kickstart config
script is below that.

The reason for the bad permissions is that the "Replace" shell function
in the capp-lspp-config script copies the permissions from the original
file when installing the CC evaluation specific ones based on information
returned from the stat(1) command, and unfortunately by default this
command uses the lstat(2) system call which does not follow symlinks -
the "-L" flag is needed to dereference them.

The "Replace" function had worked fine for RHEL3 and RHEL4 since none of
the affected files were symlinks. In RHEL5, /etc/pam.d/system-auth is a
symlink to the /etc/pam.d/system-auth-ac file, and the script now sets
the permissions to "777" based on the result of running stat(1) on the
symlink.

The authconfig RPM introduced the symlink during RHEL5 development,
apparently based on https://bugzilla.redhat.com/show_bug.cgi?id=165342 to
support local PAM config changes more easily.

A workaround for the issue in the kickstart script would be adding the
"-L" flag to the stat(1) call to avoid this and related issues in the
future. 
Comment 2 Mark J. Cox (Product Security) 2008-02-29 06:56:31 EST
Proposed fix

--- a/lspp-config/bin/capp-lspp-config.in
+++ b/lspp-config/bin/capp-lspp-config.in
@@ -1065,8 +1065,8 @@ Replace() {
          return 0
      }
      Log "Archiving $DEST"
-     MODE=$(stat -c '%a'    $DEST)
-     UG=$(  stat -c '%U.%G' $DEST)
+     MODE=$(stat -L -c '%a'    $DEST)
+     UG=$(  stat -L -c '%U.%G' $DEST)
      expr $DEST : /etc/init.d >/dev/null || {
             # don't store backups inside /etc/init.d
          Archive $DEST
  
Comment 4 Mark J. Cox (Product Security) 2008-04-01 10:25:33 EDT
removing embargo
Comment 5 Red Hat Product Security 2008-04-24 07:11:41 EDT
This issue was addressed in:

Red Hat Enterprise Linux:
  http://rhn.redhat.com/errata/RHSA-2008-0193.html


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