>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. ]
