Bugtraq mailing list archives
Re: Linux PAM (up to 0.64-2) local root compromise
From: saw () MSU RU (Savochkin Andrey Vladimirovich)
Date: Thu, 24 Dec 1998 18:02:03 +0300
--UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii On Wed, Dec 23, 1998 at 01:12:45PM +0100, Michal Zalewski wrote:
As someone said, "Never make any mistaeks." Latest release of Linux Pluggable Authentication Modules (pam-0.64-2, as well as previous ones), has huge security flaw in pam_unix_passwd.so module, which can be exploited to gain read/write permissions to /etc/shadow file.
[snip]
Default password change routine in pam_unix_passwd.so module, called from passwd utility, creates temporary file /etc/nshadow using fopen(). Unfortunately, process umask isn't changed. After approx. 3 syscalls, chmod is called to set proper mode on this file (0600). But, for these 3 syscalls, file permissions are equal to 0666 ~ umask. If umask of current process (which is inherited from parent process, of course) is set to 0, we have /etc/nshadow file with permissions 0666. Then, after all, it's moved using rename() to /etc/shadow. Cute.
Thank you for the report.
The attached patch takes care of file creation permissions in
pam_unix_passwd and pam_tally modules. I should warn people that the patch
isn't well tested. pam_unix_passwd module can't be tested on my system.
It doesn't work at all because of a glibc bug.
Best regards
Andrey V.
Savochkin
--UlVJffcvxoiEqYs2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="pam-0.65-umask.patch"
diff -ru Linux-PAM-0.65.orig/modules/pam_tally/pam_tally.c Linux-PAM-0.65/modules/pam_tally/pam_tally.c
--- Linux-PAM-0.65.orig/modules/pam_tally/pam_tally.c Thu Jan 15 01:08:33 1998
+++ Linux-PAM-0.65/modules/pam_tally/pam_tally.c Thu Dec 24 17:12:21 1998
@@ -137,13 +137,16 @@
int lstat_ret = lstat(filename,&fileinfo);
if ( lstat_ret && *tally!=TALLY_HI ) {
- if ( ( *TALLY=fopen(filename, "a") ) ) {
- /* Create file, or append-open in pathological case. */
+ int oldmask = umask(077);
+ *TALLY=fopen(filename, "a");
+ /* Create file, or append-open in pathological case. */
+ umask(oldmask);
+ if ( !*TALLY ) {
_pam_log(LOG_ALERT, "Couldn't create %s",filename);
return PAM_AUTH_ERR;
}
+ lstat_ret = fstat(fileno(*TALLY),&fileinfo);
fclose(*TALLY);
- lstat_ret = lstat(filename,&fileinfo);
}
if ( lstat_ret ) {
@@ -563,6 +566,8 @@
*argv);
exit(0);
}
+
+ umask(077);
/*
* Major difference between individual user and all users:
diff -ru Linux-PAM-0.65.orig/modules/pam_unix/pam_unix_passwd.c Linux-PAM-0.65/modules/pam_unix/pam_unix_passwd.c
--- Linux-PAM-0.65.orig/modules/pam_unix/pam_unix_passwd.c Thu Oct 9 06:59:04 1997
+++ Linux-PAM-0.65/modules/pam_unix/pam_unix_passwd.c Thu Dec 24 16:53:30 1998
@@ -554,6 +554,7 @@
int err = 0;
#ifdef HAVE_SHADOW_H
struct spwd *spwdent=NULL, *stmpent=NULL;
+ int oldmask;
#endif
if(flags & PPW_SHADOW) { retval |= PPW_SHADOW; }
gettimeofday(&time1, NULL);
@@ -583,7 +584,9 @@
return PPW_NOSUCHUSER;
spwdent->sp_pwdp = towhat;
spwdent->sp_lstchg = time(NULL)/(60*60*24);
+ oldmask = umask(077);
pwfile = fopen(SH_TMPFILE,"w");
+ umask(oldmask);
opwfile = fopen("/etc/shadow","r");
if(pwfile == NULL || opwfile == NULL)
return PPW_ERROR;
@@ -623,7 +626,9 @@
unlink(SH_TMPFILE);
} else {
pwd->pw_passwd = towhat;
+ oldmask = umask(077);
pwfile = fopen(PW_TMPFILE,"w");
+ umask(oldmask);
opwfile = fopen("/etc/passwd","r");
if(pwfile == NULL || opwfile == NULL)
return PPW_ERROR;
@@ -659,7 +664,9 @@
}
#else
pwd->pw_passwd = towhat;
+ oldmask = umask(077);
pwfile = fopen(PW_TMPFILE,"w");
+ umask(oldmask);
opwfile = fopen("/etc/passwd","r");
if(pwfile == NULL || opwfile == NULL)
return PPW_ERROR;
--UlVJffcvxoiEqYs2--
Current thread:
- Re: Verifying file data integrity using L6, (continued)
- Re: Verifying file data integrity using L6 Ng Pheng Siong (Dec 18)
- Re: Verifying file data integrity using L6 James R Grinter (Dec 20)
- Re: Verifying file data integrity using L6 Marc SCHAEFER (Dec 20)
- Re: Verifying file data integrity using L6 Curt Sampson (Dec 21)
- Why you should avoid world-writable directories D. J. Bernstein (Dec 21)
- Re: Why you should avoid world-writable directories Darren Reed (Dec 22)
- Re: Why you should avoid world-writable directories Alan Cox (Dec 22)
- Re: Why you should avoid world-writable directories Casper Dik (Dec 23)
- Re: Why you should avoid world-writable directories Martin Forssen (Dec 23)
- Linux PAM (up to 0.64-2) local root compromise Michal Zalewski (Dec 23)
- Re: Linux PAM (up to 0.64-2) local root compromise Savochkin Andrey Vladimirovich (Dec 24)
- 3COM Documentation backdoors in CB3500 Pedro Ribeiro (Dec 23)
- New perl module Net::RawIP Sergey V. Kolychev (Dec 22)
- Update on Cisco IOS 12.0 security bug John Bashinski (Dec 22)
- Re: New perl module Net::RawIP route () RESENTMENT INFONEXUS COM (Dec 22)
- [SecureXpert Labs Advisory SX-98.12.23-01] Widespread DoS Richard Reiner (Dec 23)
- Merry Christmas to Sun! (Was: L0pht NFR N-Code Modules Updated) Anonymous (Dec 23)
- Re: Merry Christmas to Sun! (Was: L0pht NFR N-Code Modules Casper Dik (Dec 24)
- Re: Merry Christmas to Sun! (Was: L0pht NFR N-Code Modules Dima Volodin (Dec 25)
- Re: Merry Christmas to Sun! (Was: L0pht NFR N-Code Modules Lamont Granquist (Dec 28)
- Re: Merry Christmas to Sun! (Was: L0pht NFR N-Code Modules Igor Schein (Dec 28)
