Bug 193146 (CVE-2006-2607)
Summary: | CVE-2006-2607 Jobs start from root when pam_limits enabled | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Josh Bressers <bressers> |
Component: | vulnerability | Assignee: | Jason Vas Dias <jvdias> |
Status: | CLOSED ERRATA | QA Contact: | Brock Organ <borgan> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | unspecified | CC: | k.georgiou, tmraz |
Target Milestone: | --- | Keywords: | Reopened, Security |
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | RHSA-2006-0539 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-07-12 18:18:02 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Josh Bressers
2006-05-25 17:11:40 UTC
This issue should also affect RHEL2 and RHEL3. This issue will be RHSA-2006:0539 Here is an additional patch from OpenBSD which adds a few extra checks. http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/cron/do_command.c.diff?r1=1.26&r2=1.27 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. Jason, Does this issue affect RHEL 2 and 3 as well? 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. 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. 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. 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 /etc/security/limits.conf: '... 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 reason. 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, THERE IS NO SERIOUS SECURITY ISSUE CAUSED BY THIS BUG IN RHEL-3 OR RHEL-4 . 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. 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 Now fixed with new vixie-cron-4.1-44.EL4 packages, respun with only the fixes for this bug. 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. http://rhn.redhat.com/errata/RHSA-2006-0539.html |