Cron not checking setgid return value

Bug #46649 reported by Brian Brazil
258
Affects Status Importance Assigned to Milestone
cron (Debian)
Fix Released
Unknown
cron (Ubuntu)
Fix Released
Medium
Jamie Strandboge
Dapper
Fix Released
Medium
Jamie Strandboge
Hardy
Fix Released
Medium
Jamie Strandboge
Intrepid
Fix Released
Medium
Jamie Strandboge
Jaunty
Fix Released
Medium
Jamie Strandboge
Karmic
Fix Released
Medium
Jamie Strandboge

Bug Description

From reading
http://bugs.gentoo.org/show_bug.cgi?id=134194
I noticed, while investigating, that Ubuntu cron doesn't check the return value of setgid. This was checked against the source of cron_3.0pl1-92ubuntu1.

There's probably some odd circumstances where this could lead to a user script could be left running as group "root".

Patch (untested):

--- do_command.c.orig 2006-05-25 22:29:05.000000000 +0100
+++ do_command.c 2006-05-25 22:30:01.000000000 +0100
@@ -296,7 +296,13 @@
                /* set our directory, uid and gid. Set gid first, since once
                 * we set uid, we've lost root privledges.
                 */
- setgid(e->gid);
+ if (setgid(e->gid) !=0) {
+ char msg[256];
+ snprintf(msg, 256, "do_command:setgid(%lu) failed: %s",
+ (unsigned long) e->uid, strerror(errno));
+ log_it("CRON",getpid(),"error",msg);
+ exit(ERROR_EXIT);
+ }
 # if defined(BSD) || defined(POSIX)
                initgroups(env_get("LOGNAME", e->envp), e->gid);
 # endif

Revision history for this message
Gary Coady (garycoady) wrote :

Confirming.

Changed in cron:
status: Unconfirmed → Confirmed
Revision history for this message
Brian Brazil (bbrazil) wrote : cron setgid+initgroups fix

Check for errors on both setgid and initgroups

Revision history for this message
Brian Brazil (bbrazil) wrote :

Doh, called diff the wrong way around. Add -R to patch to get the patch to work.

The patch also fixes the call to initgroups. As it stands, the user script could be left running with root's secondary groups.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Hrm, this was mistakenly marked as 'not-affected' in our CVE tracker.

Changed in cron (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
status: Confirmed → Triaged
Changed in cron (Ubuntu Dapper):
status: New → Fix Committed
importance: Undecided → Medium
assignee: nobody → Jamie Strandboge (jdstrand)
Changed in cron (Ubuntu Hardy):
status: New → Fix Committed
importance: Undecided → Medium
assignee: nobody → Jamie Strandboge (jdstrand)
Changed in cron (Ubuntu Intrepid):
status: New → Fix Committed
importance: Undecided → Medium
assignee: nobody → Jamie Strandboge (jdstrand)
Changed in cron (Ubuntu Jaunty):
status: New → Fix Committed
importance: Undecided → Medium
assignee: nobody → Jamie Strandboge (jdstrand)
Changed in cron (Ubuntu Karmic):
status: Triaged → In Progress
Changed in cron (Debian):
status: Unknown → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cron - 3.0pl1-106ubuntu1

---------------
cron (3.0pl1-106ubuntu1) karmic; urgency=low

  * Merge from debian unstable, remaining changes:
    - debian/control: Depend on lsb-base >= 3.2-12ubuntu4
    - debian/control: Drop MTA and lockfile-args to Suggests
    - pathnames.h: use sensible-editor
  * New Debian release fixes LP: #46649

cron (3.0pl1-106) unstable; urgency=high

   * SECURITY UPDATE: cron does not check the return code of setgid() and
   initgroups(), which under certain circumstances could cause
   applications to run with elevated group privileges. Note that the more
   serious issue of not checking the return code of setuid() was fixed already
   in 3.0pl1-64. (Closes: #528434)
    - do_command.c: check return code of setgid() and initgroups()
    - This fixes (hopefully completely) CVE-2006-2607
   * crontab.c:
      - close the temporary file after it is edited and
        before calling cleanup_tmp_crontab() to behave properly on NFS
        mounted / (Closes: #413962)
      - if crontab is run without argument then it will read stdin to replace
        the users crontab. This way it is POSIXLY_CORRECT. More information at
        http://www.opengroup.org/onlinepubs/9699919799/utilities/crontab.html
        (Closes: #514062)
   * crontab.5 :
      - Add details about multiple recipients in MAILTO (LP: #235464)
        (Closes: #502650)
      - Indicate that it also reads environment from /etc/environment
      - Substitute ATT for AT&T (Closes: #405474)
   * Proper fix for PAM configuration to make cron read the system
     environment (Closes: #511684)
   * debian/cron.init:
       - Add support for 'status' in the init.d (Closes: #514721)
       - Use 'cron' instead of 'crond' (Closes: #497699)
   * Change lockfile-progs from Suggests: to Recommends: and remove wording
     related to dselect, which is no longer relevant (Closes: #452460, #468262)
   * Change the (outdated) wording of the description based on an example
     provided by Justin B Rye (Closes: 485452)
   * Change the postinst so that update-rc.d is only run if /etc/init.d/cron is
     executable (Closes: #500610)

 -- Jamie Strandboge <email address hidden> Thu, 14 May 2009 09:53:08 -0500

Changed in cron (Ubuntu Karmic):
status: In Progress → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cron - 3.0pl1-105ubuntu1.1

---------------
cron (3.0pl1-105ubuntu1.1) jaunty-security; urgency=low

  * SECURITY UPDATE: cron does not check the return code of setgid() and
    initgroups(), which under certain circumstances could cause applications
    to run with elevated group privileges. Note that the more serious issue
    of not checking the return code of setuid() was fixed in 3.0pl1-64.
    (LP: #46649)
    - do_command.c: check return code of setgid() and initgroups()
    - CVE-2006-2607

 -- Jamie Strandboge <email address hidden> Tue, 12 May 2009 12:37:40 -0500

Changed in cron (Ubuntu Jaunty):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cron - 3.0pl1-104+ubuntu5.1

---------------
cron (3.0pl1-104+ubuntu5.1) intrepid-security; urgency=low

  * SECURITY UPDATE: cron does not check the return code of setgid() and
    initgroups(), which under certain circumstances could cause applications
    to run with elevated group privileges. Note that the more serious issue
    of not checking the return code of setuid() was fixed in 3.0pl1-64.
    (LP: #46649)
    - do_command.c: check return code of setgid() and initgroups()
    - CVE-2006-2607

 -- Jamie Strandboge <email address hidden> Tue, 12 May 2009 12:36:59 -0500

Changed in cron (Ubuntu Intrepid):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cron - 3.0pl1-100ubuntu2.1

---------------
cron (3.0pl1-100ubuntu2.1) hardy-security; urgency=low

  * SECURITY UPDATE: cron does not check the return code of setgid() and
    initgroups(), which under certain circumstances could cause applications
    to run with elevated group privileges. Note that the more serious issue
    of not checking the return code of setuid() was fixed in 3.0pl1-64.
    (LP: #46649)
    - do_command.c: check return code of setgid() and initgroups()
    - CVE-2006-2607

 -- Jamie Strandboge <email address hidden> Tue, 12 May 2009 12:36:21 -0500

Changed in cron (Ubuntu Hardy):
status: Fix Committed → Fix Released
Revision history for this message
Jamie Strandboge (jdstrand) wrote :
Changed in cron (Ubuntu Dapper):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.