suexec/1001: Potential group security hole with suexec

[Patrick Rigney <pa...@evocative.com>]

>Number:         1001
>Category:       suexec
>Synopsis:       Potential group security hole with suexec
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache (Apache HTTP Project)
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Sat Aug 16 13:40:01 1997
>Originator:     patrick@evocative.com
>Organization:
apache
>Release:        1.2.1
>Environment:
FreeBSD 2.2.2-RELEASE, gcc 2.7.2.1
>Description:
suexec will setuid/setgid to user who has group membership below GID_MIN.
For example, if a user "fred" with groups wheel(0) staff(20) and fred(1022) appears
in the User directive of a virtual host, and that vhost uses suexec, then
suexec cgis will run within "wheel" (and other above) group privs.  The Group
directive is not effective in limiting groups for the suexec, and in fact adds
to the group membership.  For example, specifying group "nobody" would make the
list of groups "nobody, wheel, staff, fred" for the above.  This can be easily
exploited if the user's CGI or cgi-bin is writable by other users (perhaps
through permission via other groups mentioned, e.g. staff).
>How-To-Repeat:
Select/create a user with membership in a few low groups (< GID_MIN).  Create a
vhost and set it up for suexec, using that user in the User directive. A simple
shell CGI scipt that runs /usr/bin/whoami and /usr/bin/groups and displays their output will
show the effect.
>Fix:
The grouplist should be checked after setgid()/initgroups(), and at a minimum a 
warning issued to the log, perhaps with a compile-time option to abort.
Or (my personal preference) setgroups() could be used to limit the grouplist
to only that group specified in the Group directive, or only those >= GID_MIN
>Audit-Trail:
>Unformatted:

Re: suexec/1001: Potential group security hole with suexec

[Dean Gaudet <dg...@arctic.org>]

This looks ugly.

Dean

On Sat, 16 Aug 1997, Patrick Rigney wrote:

> 
> >Number:         1001
> >Category:       suexec
> >Synopsis:       Potential group security hole with suexec
> >Confidential:   no
> >Severity:       serious
> >Priority:       medium
> >Responsible:    apache (Apache HTTP Project)
> >State:          open
> >Class:          sw-bug
> >Submitter-Id:   apache
> >Arrival-Date:   Sat Aug 16 13:40:01 1997
> >Originator:     patrick@evocative.com
> >Organization:
> apache
> >Release:        1.2.1
> >Environment:
> FreeBSD 2.2.2-RELEASE, gcc 2.7.2.1
> >Description:
> suexec will setuid/setgid to user who has group membership below GID_MIN.
> For example, if a user "fred" with groups wheel(0) staff(20) and fred(1022) appears
> in the User directive of a virtual host, and that vhost uses suexec, then
> suexec cgis will run within "wheel" (and other above) group privs.  The Group
> directive is not effective in limiting groups for the suexec, and in fact adds
> to the group membership.  For example, specifying group "nobody" would make the
> list of groups "nobody, wheel, staff, fred" for the above.  This can be easily
> exploited if the user's CGI or cgi-bin is writable by other users (perhaps
> through permission via other groups mentioned, e.g. staff).
> >How-To-Repeat:
> Select/create a user with membership in a few low groups (< GID_MIN).  Create a
> vhost and set it up for suexec, using that user in the User directive. A simple
> shell CGI scipt that runs /usr/bin/whoami and /usr/bin/groups and displays their output will
> show the effect.
> >Fix:
> The grouplist should be checked after setgid()/initgroups(), and at a minimum a 
> warning issued to the log, perhaps with a compile-time option to abort.
> Or (my personal preference) setgroups() could be used to limit the grouplist
> to only that group specified in the Group directive, or only those >= GID_MIN
> >Audit-Trail:
> >Unformatted:
> 
> 
>