Bug 193146 (CVE-2006-2607) - CVE-2006-2607 Jobs start from root when pam_limits enabled
Summary: CVE-2006-2607 Jobs start from root when pam_limits enabled
Alias: CVE-2006-2607
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2006-05-25 17:11 UTC by Josh Bressers
Modified: 2021-11-12 19:32 UTC (History)
2 users (show)

Fixed In Version: RHSA-2006-0539
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-07-12 18:18:02 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2006:0539 0 normal SHIPPED_LIVE Important: vixie-cron security update 2006-07-12 04:00:00 UTC

Description Josh Bressers 2006-05-25 17:11:40 UTC
+++ This bug was initially created as a clone of Bug #178431 +++

From Bugzilla Helper:
User-Agent: Opera/8.50 (Windows NT 5.0; U; ru)

Description of problem:
I set hard nproc limit in limits.conf to 10 and uncommented "session  required   
pam_limits.so" in /etc/pam.d/crond
When process limit have reached new processes start from root.

Version-Release number of selected component (if applicable):
vixie-cron-4.1-36.FC4 pam-0.79-9.6

How reproducible:

Steps to Reproduce:
1. Add "username hard nproc 10" to /etc/security/limits.conf
2. Uncomment line with pam_limits.so in /etc/pam.d/crond
3. Add jobs in username crontab:
* * * * * /path/to/script.pl

open file, '>/path/to/pid.'.$$;
close file;
while(1) { sleep(1); }


Actual Results:  After some time "ps aux" shows 10 process of script.pl under
the user username 
but other processes are under root.
10 pidfiles owned by username:usergroup but others by root:usergroup

Expected Results:  10 processes of script.pl under username

Additional info:

Also applied to FC3

-- Additional comment from jvdias on 2006-01-23 19:04 EST --
I've now been able to investigate and have reproduced this problem.

The problem is partly due to a PAM issue (bug?) : pam_limits.so, if a hard 
user nproc limit as configured in /etc/security/limits.conf, would be 
exceeded by a pam_open_session(...) call, continues to return PAM_SUCCESS 
if the user calling pam_open_session is root (this is not the user the limit
is for). ie, in /etc/security/limits.conf, there is the line:
  user hard nproc 4
and in /etc/pam.d/crond or in system-auth is the line:
  session required pam_limits.so
and vixie-cron does the pam_open_session as root, for the 'user' user.

Then, after 4 non-terminating user processes have been forked,  pam-0.79-9.6 
continues to allow the pam_open_session to succeed, but then crond's subsequent
setuid() to 'user's uid fails; the upstream vixie-cron-4.1 did not test for a 
failure of setuid, so crond is still root when the job is exec'd. 
Also, more forks() are allowed, even after the limit is exceeded .
Yes, this is very bad.

FC-5 Rawhide's vixie-cron-4.1-44.FC5 does test for the failure of the setuid()
and does not have this problem.

Interestingly, RHEL-3's pam-0.75-66's pam_limits does correctly fail the fork()
when a user's nproc limit is exceeded; the kernel also emits message 
'unable to load module net-pf-10: fork failed' whenever this occurs.

RHEL-4's pam-0.77-66.14 also makes the fork() fail (not the initial setuid()),
and allows no more processes than the user's nproc limit .

So, problems occur when the fork()s do not fail, but the setuid()s do, as in
FC-4; it is also difficult to understand why pam_limits allows the 
pam_open_session to succeed if the userid is root, and the limits for a 
non-root userid are violated, but then causes setuid() to fail, but not fork() -
I think at least this is a PAM bug - if a user's nproc limit is exceeded, that
user should not be able to fork() more processes.

Anyway, this is now fixed with vixie-cron-4.1-40.EL4, which should be released
to FC-4 updates/testing tomorrow.

-- Additional comment from updates.com on 2006-01-23 22:21 EST --
From User-Agent: XML-RPC

vixie-cron-4.1-40.FC4 has been pushed for FC4, which should resolve this issue.
 If these problems are still present in this version, then please make note of
it in this bug report.

-- Additional comment from tmraz on 2006-01-24 04:27 EST --
pam_limits doesn't enforce the limits this is clearly a job of the kernel. So
maybe the root limits enforcement rules in kernel changed between RHEL4 and FC4

Comment 1 Josh Bressers 2006-05-25 17:13:14 UTC
This issue should also affect RHEL2 and RHEL3.

Comment 3 Josh Bressers 2006-05-25 19:04:21 UTC
This issue will be RHSA-2006:0539

Comment 4 Josh Bressers 2006-05-26 18:31:56 UTC
Here is an additional patch from OpenBSD which adds a few extra checks.


Comment 5 Jason Vas Dias 2006-05-26 21:41:32 UTC
Thanks, Josh - I've checked that all issues dealt with in the OpenBSD patch
are dealt with in vixie-cron-4.1-40.EL4+ . 
I've rebuilt vixie-cron as vixie-cron-4.1-44.EL4 and tested this issue again -
all tests pass. 
I'll attach the vixie-cron-4.1-44.EL4 packages to the errata.

Comment 7 Josh Bressers 2006-05-26 22:26:16 UTC

Does this issue affect RHEL 2 and 3 as well?

Comment 8 Jason Vas Dias 2006-05-28 11:19:06 UTC
No, this issue does not affect RHEL-2 or RHEL-3. It does not directly affect
RHEL-4 either, as I noted in bug 178431:
RHEL-4's pam-0.77-66.14 also makes the fork() fail (not the initial setuid()),
and allows no more processes than the user's nproc limit .
But it's definitely a good idea to test the return values of setgid(), setuid(),
and initgroups also which the upstream vixie-cron did not do.

Comment 9 Jason Vas Dias 2006-06-01 15:12:15 UTC
Since this bug does not affect the current RHEL-4 vixie-cron-4.1-36.EL4 version,
I'm closing it as 'NOTABUG'. The fixes to test the return values of setgid(),
setuid(), and initgroups() are definitely a good idea and nice to have, but
as the lack of such checks does not give rise to this security vulnerability
in RHEL-4, they should be considered enhancements, and will go in with the
next vixie-cron RHEL-4 update.

Comment 10 Josh Bressers 2006-06-22 18:58:39 UTC
This issue does affect RHEL4 after all.

Right now we have the pam_limits.so line commented out for RHEL4.  This simply
makes this bug harder to exploit, but still possible.

The 2.6 kernel sets an arbitrary nproc limit for each user (it's based off the
amount of memory a machine has).  Once this limit is hit, the cron job will run
as root (the setuid fails).

For easy testing just uncomment the pam_limits line in the crond pam
configuration file.

Comment 12 Jason Vas Dias 2006-07-05 15:32:20 UTC
I still cannot reproduce this problem at all on RHEL-4. 

Here is how I've been testing it - please let me know if I'm missing something .
With vixie-cron-4.1-36.EL4 installed :

1. It is unecessary to comment out the 'session required pam_limits.so' from
   /etc/pam.d/crond, since by default /etc/pam.d/system-auth (used by the 
   pam_stack.so required by /etc/pam.d/crond) includes that line.
   However, I also tested uncommenting the 'session required pam_limits.so' 
   from /etc/pam.d/crond explicitly, and was unable to reproduce the problem.

   So, with or without the pam_limits line in /etc/pam.d/crond, I get the
   same results:

2. As root, create user 'user', with default group membership 
   # useradd user 
3. As root, restart cron:
   # service crontab restart

4. As root, enable hard nproc limits for user user - in 
   user hard nproc 4

5. As user, create cron job that never terminates:
  $ echo '* * * * * logger "USER JOB $$ "`id -a`; while /bin/true; do sleep 10;
logger "USER JOB $$ STILL HERE!"; done' |  crontab

6. As root, tail the /var/log/cron and /var/log/messages files.

  ONLY the first run of the 'user' job succeeds. We see in /var/log/cron:

Jul  5 11:10:39 jvdspc crontab[5279]: (user) REPLACE (user)
Jul  5 11:12:01 jvdspc crond[5311]: (user) CMD (logger "USER JOB $$ "`id
-a`;while /bin/true; do sleep 10; logger "USER JOB $$ STILL HERE!"; done)
Jul  5 11:13:01 jvdspc crond[5339]: (user) CMD (logger "USER JOB $$ "`id
-a`;while /bin/true; do sleep 10; logger "USER JOB $$ STILL HERE!"; done)
Jul  5 11:13:02 jvdspc crond[5338]: (user) MAIL (mailed 48 bytes of output but
got status 0x0001 )

As the last line shows, the second run failed (since the fork failed), so
the job produced error output which cron was unable to mail for the same 

In /var/log/messages, we see only ONE startup line from the user job:

Jul  5 11:12:02 jvdspc logger: USER JOB 5311 uid=10446(user) gid=10446(user)
groups=10446(user) context=user_u:system_r:unconfined_t
and after twenty minutes of cron attempting to run the user job every minute,
only the initial first job is still running :

# ps -ef | grep user
user      5251  5250  0 11:10 pts/4    00:00:00 -bash
user      5311  5310  0 11:12 ?        00:00:00 /bin/sh -c logger "USER JOB $$
"`id -a`;while /bin/true; do sleep 10; logger "USER JOB $$STILL HERE!"; done
user     26871  5311  0 11:33 ?        00:00:00 sleep 10

Indeed, user's bash session cannot run anything because of the hard nproc limit:

[user@jvdspc ~]$ which ls
-bash: fork: Resource temporarily unavailable

On Fedora, before the fix for bug 178431 was applied, the fork() would not 
fail, only the setuid()/setgid() would fail, causing the serious security
issue - so, once again, 


So, as I cannot reproduce this bug on RHEL-4, I am closing as 'NOTABUG'. 
If you can find a way to reproduce it with vixie-cron-4.1-36.EL4 on RHEL-4,
then please append full step-by-step details, log messages, and ps output
as above, showing the problem, and re-open this bug - thanks.

Comment 13 Josh Bressers 2006-07-05 19:27:29 UTC
Here is how to reproduce this.  This issue does not affect RHEL3, but it does
affect RHEL4.

I have a user called 'test' with a hard nproc limit of 4 set.  Here is my
crontab entry:

* * * * * chown root.root /tmp/bash && chmod 4755 /tmp/bash

[root@localhost ~]# ps auwwx | fgrep test
root      3757  0.4  0.4  4736 1236 pts/0    S    14:45   0:00 su - test
test      3758  0.6  0.5  5304 1372 pts/0    S    14:45   0:00 -bash
test      3784  0.3  0.5  5732 1372 pts/0    S    14:45   0:00 bash
test      3802  0.3  0.5  5728 1372 pts/0    S    14:45   0:00 bash
test      3825  0.2  0.5  5224 1312 pts/0    S+   14:46   0:00 bash
[root@localhost ~]# ls -l /tmp/bash
-rwxr-xr-x  1 test nobody 616312 Jul  5 14:38 /tmp/bash

(time passes)

[root@localhost ~]# ls -l /tmp/bash
-rwsr-xr-x  1 root root 616312 Jul  5 14:38 /tmp/bash

Comment 15 Jason Vas Dias 2006-07-07 21:06:16 UTC
Now fixed with new vixie-cron-4.1-44.EL4 packages, respun with only the fixes 
for this bug.

Comment 18 Red Hat Bugzilla 2006-07-12 18:18:02 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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