>Number: 2580 >Category: general >Synopsis: CGI/ >Confidential: no >Severity: serious >Priority: medium >Responsible: apache >State: open >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Thu Jul 9 20:50:00 PDT 1998 >Last-Modified: >Originator: [EMAIL PROTECTED] >Organization: apache >Release: 1.3.0 >Environment: All Unix variants >Description: Some consideration should be given to the use of initgroups() in set_group_privs() with MULTIPLE_GROUPS undefined by default.
With MULTIPLE_GROUPS undefined, an attempt to execute a script which is group executable and whose group is not that used for the setgid() but is in the supplementary group list will fail do to permissions checks in ap_can_exec(). A CGI script can be written which exploits the permissions available to the groups in the script�s supplementary groups. This, of course, could include programs that are setuid. Although this is basically "normal" behavior, the effect of MULTIPLE_GROUPS being undefined (by default) is not. It is odd and misleading: a CGI script which can't be exec'd by Apache, can be exec'd by another script which was exec'd by Apache. Of course this won�t effect most configurations (i.e. those which choose appropriate uid/gids), but given Apache�s prevalence that leaves lots of susceptible installations. It�s probably not wise at this point to define MULTIPLE_GROUPS as the default. Using setgroups() to set the supplementary group list with just the one gid instead of using initgroups() (when MULTIPLE_GROUPS is not defined) would be simple, safer, and not effect existing installations (I can�t imagine anyone is making use of supplementary groups without defining MULTIPLE_GROUPS). PR#1001 addresses a related topic. If you concur, I'll write a patch. robs >How-To-Repeat: >Fix: >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include <[EMAIL PROTECTED]> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
