Bug 327 - root leak in sudo/sudoers 1.6.9
root leak in sudo/sudoers 1.6.9
Status: RESOLVED FIXED
Product: Sudo
Classification: Unclassified
Component: Sudo
1.6.9
PC Linux
: normal security
Assigned To: Todd C. Miller
: 321 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-23 12:21 MST by Harald Koenig
Modified: 2009-02-03 09:20 MST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Koenig 2009-01-23 12:21:44 MST
at least in 1.6.9p17 to p19 valid sudoers rules might give users root access without password authentication.  version 1.7.0 seems to be correct (but there are _many_ 1.6.9p* installations out there)

details via private mail to Todd Miller and Thomas Biege, Marcus Meissner from opensuse-security...
Comment 1 Harald Koenig 2009-01-29 13:40:53 MST
(In reply to comment #0)
> at least in 1.6.9p17 to p19 valid sudoers rules might give users root
> access without password authentication.  version 1.7.0 seems to be
> correct (but there are _many_ 1.6.9p* installations out there)
> 
> details via private mail to Todd Miller and Thomas Biege, Marcus
> Meissner from opensuse-security...


now, here is my original bug report:

--- 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ---
at least sudo 1.6.9p17 to 1.6.9p19 show the following problem
(1.7.0 is ok for my quick test):

using the following in sudoers

        Runas_Alias RUNASLIST = koenig,%video
        harald ALL=(RUNASLIST) NOPASSWD: ALL

I try to allow user "harald" to switch to user koenig and to all users
in group video. this intended funtionality works fine.

BUT iff user harald _is_ in group video himself, then harald can sudo
to _any_ user without password -- including root!  the output of "sudo -l"
does not show this "feature", fortuneately;)

if harald does not belong to group video, everything is fine and only
switching to users in group video is allowed without password.


we found this problem in 1.6.9p17 (local build) and verified for 1.6.9p18/19 too,
including the 1.6.9p19 binary being shipped in openSUSE 11.1 (sudo-1.6.9p17-10.35 x86_64).

only my 1.7.0 build (all 64 bit btw) works as expected.

[ ... ]

since 1.7.0 code changed significantly since p19, it would be nice
to release a 1.6.9p20 security fix, isn't it ?!


btw: do you expect such security problems to be reported via the
public mailing lists or bugzilla or similar, or what's the correct/best
place to report such issues first ?


I've created "empty" bugzilla entries for now:

     http://www.gratisoft.us/bugzilla/show_bug.cgi?id=327

     https://bugzilla.novell.com/show_bug.cgi?id=468923

--- 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ---

and I verified the patch below from Todd C. Miller which fixed our problem.
the patch is now available here

    http://www.sudo.ws/cgi-bin/cvsweb/sudo/parse.c.diff?r1=1.160.2.21&r2=1.160.2.22&f=h


--- 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ---
Index: parse.c
===================================================================
RCS file: /home/cvs/courtesan/sudo/parse.c,v
retrieving revision 1.160.2.21
diff -u -r1.160.2.21 parse.c
--- parse.c     2 Nov 2008 14:35:53 -0000       1.160.2.21
+++ parse.c     23 Jan 2009 19:16:55 -0000
@@ -651,9 +651,11 @@
     /*
      * If the user has a supplementary group vector, check it first.
      */
-    for (i = 0; i < user_ngroups; i++) {
-       if (grp->gr_gid == user_groups[i])
-           return(TRUE);
+    if (strcmp(user, user_name) == 0) {
+       for (i = 0; i < user_ngroups; i++) {
+           if (grp->gr_gid == user_groups[i])
+               return(TRUE);
+       }
     }
     if (grp->gr_mem != NULL) {
        for (cur = grp->gr_mem; *cur; cur++) {
--- 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ---


thanks for the quick response!
Comment 2 Todd C. Miller 2009-02-03 09:17:31 MST
Fixed in sudo-1.6.9p20
Comment 3 Todd C. Miller 2009-02-03 09:20:53 MST
*** Bug 321 has been marked as a duplicate of this bug. ***