[Zope] supplemental group ids (Linux)
I noticed when starting Zope as root (to get privilaged ports),
but requesting suid to `nobody' (start -u nobody) the resulting
processes have the correct uid and gid, but the supplemental
group id list still has the appropriate value for root. This
means that the Zope process could, for example, write to files
that may belong to root.
It's not clear whether this deserves a bug report, so I though
I'd ask here instead.
The fix is easy (and very lightly tested):
1) grab and install the supplemental gid package (for python)
http://www.ccraig.org/software/group.c
2) patch (for 2.2.0)
--- z2.py.orig Fri Jun 30 10:23:53 2000
+++ z2.py Mon Sep 4 14:33:51 2000
@@ -682,13 +682,20 @@
if type(UID) == type(""):
uid = pwd.getpwnam(UID)[2]
gid = pwd.getpwnam(UID)[3]
+uname = UID
elif type(UID) == type(1):
uid = pwd.getpwuid(UID)[2]
gid = pwd.getpwuid(UID)[3]
+uname = pwd.getpwuid(UID)[1]
else:
raise KeyError
try:
if gid is not None:
+try:
+import group
+group.initgroups(uname, gid)
+except:
+pass
try:
os.setgid(gid)
except OSError:
___
Zope maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] supplemental group ids (Linux)
Aplogies for the ignorance, but can you maybe explain the concept
of supplemental group ids and give an example of how the current unpatched
behavior could be subverted?
On 4 Sep 2000 [EMAIL PROTECTED] wrote:
> I noticed when starting Zope as root (to get privilaged ports),
> but requesting suid to `nobody' (start -u nobody) the resulting
> processes have the correct uid and gid, but the supplemental
> group id list still has the appropriate value for root. This
> means that the Zope process could, for example, write to files
> that may belong to root.
>
> It's not clear whether this deserves a bug report, so I though
> I'd ask here instead.
>
>
> The fix is easy (and very lightly tested):
>
> 1) grab and install the supplemental gid package (for python)
>http://www.ccraig.org/software/group.c
>
> 2) patch (for 2.2.0)
>
> --- z2.py.origFri Jun 30 10:23:53 2000
> +++ z2.py Mon Sep 4 14:33:51 2000
> @@ -682,13 +682,20 @@
> if type(UID) == type(""):
> uid = pwd.getpwnam(UID)[2]
> gid = pwd.getpwnam(UID)[3]
> +uname = UID
> elif type(UID) == type(1):
> uid = pwd.getpwuid(UID)[2]
> gid = pwd.getpwuid(UID)[3]
> +uname = pwd.getpwuid(UID)[1]
> else:
> raise KeyError
> try:
> if gid is not None:
> +try:
> +import group
> +group.initgroups(uname, gid)
> +except:
> +pass
> try:
> os.setgid(gid)
> except OSError:
>
>
> ___
> Zope maillist - [EMAIL PROTECTED]
> http://lists.zope.org/mailman/listinfo/zope
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope-announce
> http://lists.zope.org/mailman/listinfo/zope-dev )
>
Chris McDonough
Digital Creations, Publishers of Zope
http://www.zope.org
___
Zope maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] supplemental group ids (Linux)
Chris McDonough <[EMAIL PROTECTED]> wrote: >Aplogies for the ignorance, but can you maybe explain the concept >of supplemental group ids and give an example of how the current unpatched >behavior could be subverted? I can try... Supplemental gids are useful for allowing a user to belong to more than one group, or maybe to more than one project in normal parlance. This is normally effected by listing the uid opposite more than one group in /etc/group. The login process issues the initgroups(3) call to install these supplemental groups, which are inherited by all processes forked from the login shell. The problem is comes when you change user ids; for example what I saw with Zope (start -u nobody) was: before change after change = user id root nobody group idroot nobody sup id(s) root root Thus the process has group access privilages for nobody (correct) and root (bad) in unpatched Zope. I cannot give you an exploit based on this -- my knowledge of Zope is not deep enough -- and in a bug free world there probably would be no exploit. But the reason for running as nobody, I think, is to contain damage should an exploit be found. For that reason, it would seem reasonable to change the supplemental gids too. I saw this on Linux; supplemental groups come from the BSD tradition, so you likely will find the same situation on *BSD, Solaris, etc. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] supplemental group ids (Linux)
On 4 Sep 2000 [EMAIL PROTECTED] wrote: I see... well, maybe we can take a look at it. In the meantime, if you figure out a patch that doesn't rely on an external program, let me know... Thanks, C > Chris McDonough <[EMAIL PROTECTED]> wrote: > >Aplogies for the ignorance, but can you maybe explain the concept > >of supplemental group ids and give an example of how the current unpatched > >behavior could be subverted? > > I can try... > > Supplemental gids are useful for allowing a user to belong to more > than one group, or maybe to more than one project in normal parlance. > This is normally effected by listing the uid opposite more than one > group in /etc/group. The login process issues the initgroups(3) call > to install these supplemental groups, which are inherited by all > processes forked from the login shell. > > The problem is comes when you change user ids; for example what I > saw with Zope (start -u nobody) was: > > before change after change > = > user id root nobody > group idroot nobody > sup id(s) root root > > Thus the process has group access privilages for nobody (correct) and > root (bad) in unpatched Zope. > > I cannot give you an exploit based on this -- my knowledge of Zope > is not deep enough -- and in a bug free world there probably would > be no exploit. But the reason for running as nobody, I think, is > to contain damage should an exploit be found. For that reason, it > would seem reasonable to change the supplemental gids too. > > I saw this on Linux; supplemental groups come from the BSD tradition, > so you likely will find the same situation on *BSD, Solaris, etc. > > ___ > Zope maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope-dev ) > Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] supplemental group ids (Linux)
Kip Rugger wrote: > > Chris McDonough <[EMAIL PROTECTED]> wrote: > >Aplogies for the ignorance, but can you maybe explain the concept > >of supplemental group ids and give an example of how the current unpatched > >behavior could be subverted? > > I can try... > > Supplemental gids are useful for allowing a user to belong to more > than one group, or maybe to more than one project in normal parlance. > This is normally effected by listing the uid opposite more than one > group in /etc/group. The login process issues the initgroups(3) call > to install these supplemental groups, which are inherited by all > processes forked from the login shell. > The problem is comes when you change user ids; for example what I > saw with Zope (start -u nobody) was: > > before change after change > = > user id root nobody > group idroot nobody > sup id(s) root root Would you mind describing how you determine this? -- Do not meddle in the affairs of sysadmins, for they are easy to annoy, and have the root password. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] supplemental group ids (Linux)
| > I saw this on Linux; supplemental groups come from the BSD tradition, | > so you likely will find the same situation on *BSD, Solaris, etc. Sorry I missed the start of the thread, but, I can weigh in on this point. Using -u user under FreeBSD gives you the Primary Group for the user you have requested. Supplemental groups are available only for that user, not the user you ran Zope as. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] supplemental group ids (Linux)
Bill Anderson <[EMAIL PROTECTED]> wrote: >Kip Rugger wrote: >> >> Chris McDonough <[EMAIL PROTECTED]> wrote: >> >Aplogies for the ignorance, but can you maybe explain the concept >> >of supplemental group ids and give an example of how the current unpatched >> >behavior could be subverted? >> >> I can try... >> >> Supplemental gids are useful for allowing a user to belong to more >> than one group, or maybe to more than one project in normal parlance. >> This is normally effected by listing the uid opposite more than one >> group in /etc/group. The login process issues the initgroups(3) call >> to install these supplemental groups, which are inherited by all >> processes forked from the login shell. >> The problem is comes when you change user ids; for example what I >> saw with Zope (start -u nobody) was: >> >> before change after change >> = >> user id root nobody >> group idroot nobody >> sup id(s) root root > > >Would you mind describing how you determine this? [/proc] $ cat /proc/90/status Name: junkbuster State: S (sleeping) Pid:90 PPid: 1 Uid:101 101 101 101 Gid:101 101 101 101 Groups: 101 <-- supplemental groups VmSize: 1348 kB VmLck: 0 kB VmRSS: 436 kB VmData: 192 kB VmStk:84 kB VmExe:92 kB VmLib: 952 kB SigPnd: SigBlk: SigIgn: 80011006 SigCgt: CapInh: feff CapPrm: CapEff: On my machine 101 is uid and gid for nobody; as you can see junkbuster is correctly sandboxed. For unmodified Zope, you'll see a zero in the indicated line (or possibly several values if root belongs to several groups like `wheel' on your system). ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] supplemental group ids (Linux)
Andrew Kenneth Milton <[EMAIL PROTECTED]> wrote: > >| > I saw this on Linux; supplemental groups come from the BSD tradition, >| > so you likely will find the same situation on *BSD, Solaris, etc. > >Sorry I missed the start of the thread, but, I can weigh in on this point. > >Using -u user under FreeBSD gives you the Primary Group for the user you >have requested. Supplemental groups are available only for that user, not >the user you ran Zope as. Interesting. NetBSD has the Linux behaviour. The Apache CGI wrapper does setgid and initgroups, in that order. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] supplemental group ids (Linux)
+---[ Kip Rugger ]-- | | On my machine 101 is uid and gid for nobody; as you can see | junkbuster is correctly sandboxed. For unmodified Zope, you'll | see a zero in the indicated line (or possibly several values | if root belongs to several groups like `wheel' on your system). Have you actually tried to change to that group? -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] supplemental group ids (Linux)
After some digging, it appears that this is a really good find. Thanks
very much for reporting it. I am going to add a collector item with your
message verbatim.
Thanks very much!
- C
On 4 Sep 2000 [EMAIL PROTECTED] wrote:
> I noticed when starting Zope as root (to get privilaged ports),
> but requesting suid to `nobody' (start -u nobody) the resulting
> processes have the correct uid and gid, but the supplemental
> group id list still has the appropriate value for root. This
> means that the Zope process could, for example, write to files
> that may belong to root.
>
> It's not clear whether this deserves a bug report, so I though
> I'd ask here instead.
>
>
> The fix is easy (and very lightly tested):
>
> 1) grab and install the supplemental gid package (for python)
>http://www.ccraig.org/software/group.c
>
> 2) patch (for 2.2.0)
>
> --- z2.py.origFri Jun 30 10:23:53 2000
> +++ z2.py Mon Sep 4 14:33:51 2000
> @@ -682,13 +682,20 @@
> if type(UID) == type(""):
> uid = pwd.getpwnam(UID)[2]
> gid = pwd.getpwnam(UID)[3]
> +uname = UID
> elif type(UID) == type(1):
> uid = pwd.getpwuid(UID)[2]
> gid = pwd.getpwuid(UID)[3]
> +uname = pwd.getpwuid(UID)[1]
> else:
> raise KeyError
> try:
> if gid is not None:
> +try:
> +import group
> +group.initgroups(uname, gid)
> +except:
> +pass
> try:
> os.setgid(gid)
> except OSError:
>
>
> ___
> Zope maillist - [EMAIL PROTECTED]
> http://lists.zope.org/mailman/listinfo/zope
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope-announce
> http://lists.zope.org/mailman/listinfo/zope-dev )
>
Chris McDonough
Digital Creations, Publishers of Zope
http://www.zope.org
___
Zope maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] supplemental group ids (Linux)
Kip Rugger wrote: > > Bill Anderson <[EMAIL PROTECTED]> wrote: > >Kip Rugger wrote: > >> > >> Chris McDonough <[EMAIL PROTECTED]> wrote: > >> >Aplogies for the ignorance, but can you maybe explain the concept > >> >of supplemental group ids and give an example of how the current unpatched > >> >behavior could be subverted? > >> > >> I can try... > >> > >> Supplemental gids are useful for allowing a user to belong to more > >> than one group, or maybe to more than one project in normal parlance. > >> This is normally effected by listing the uid opposite more than one > >> group in /etc/group. The login process issues the initgroups(3) call > >> to install these supplemental groups, which are inherited by all > >> processes forked from the login shell. > >> The problem is comes when you change user ids; for example what I > >> saw with Zope (start -u nobody) was: > >> > >> before change after change > >> = > >> user id root nobody > >> group idroot nobody > >> sup id(s) root root > > > > > >Would you mind describing how you determine this? > > [/proc] $ cat /proc/90/status > Name: junkbuster > State: S (sleeping) > Pid:90 > PPid: 1 > Uid:101 101 101 101 > Gid:101 101 101 101 > Groups: 101 <-- supplemental groups > On my machine 101 is uid and gid for nobody; as you can see > junkbuster is correctly sandboxed. For unmodified Zope, you'll > see a zero in the indicated line (or possibly several values > if root belongs to several groups like `wheel' on your system). OK, something is not quite right here. On my unmodified zope, it is properly 'sandboxed'. Perhaps it is the use of the explicit '-u nobody'? I don't do that on my system, which causes Zope to run as nobody implicitly. (When started as root, unless told otherwise, zope will switch to nobody). Try running without the 'u nobody switch, and see what happens. Just out of curiousity. -- Do not meddle in the affairs of sysadmins, for they are easy to annoy, and have the root password. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] supplemental group ids (Linux)
>OK, something is not quite right here.
>On my unmodified zope, it is properly 'sandboxed'. Perhaps it is the use of
>the explicit '-u nobody'? I don't do that on
>my system, which causes Zope to run as nobody implicitly.
>
>(When started as root, unless told otherwise, zope will switch to nobody).
>
>Try running without the 'u nobody switch, and see what happens. Just out of
>curiousity.
No difference.
I think the point is that Zope does not make any initgroups(3) calls;
this will be a problem if the particular system needs it.
I have two such systems:
Linux 2.2.16 + glibc-2.1.2
NetBSD 1.4
Having reviewed the kernel and libc sources in both cases, I am convinced
that set*gid and {init,set,get}groups operate totally independently.
At minimum, initgroups is used by login/su to set the primary gid found
in /etc/passwd, plus any additional gids associated with the uid in
/etc/group, as supplemental gids. Thus, even if there are no supplemental
gids in /etc/group, you still have the primary gid in the kernel's list
of supplementals. So the primary gid occurs initially in 3 places:
the real and effective gids, and one of the supplemental gids.
You must get all 3; setgid for real and eff, initgroups for sup.
(Additionally in linux you have the `saved' gid and the fsgid, but
setgid will modify them.)
Under this hypothesis, my question is how could _your_ system work?
Why is it that you don't have the original primary gid lingering in
the supplemental list?
___
Zope maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] supplemental group ids (Linux)
Kip Rugger wrote: > > >OK, something is not quite right here. > >On my unmodified zope, it is properly 'sandboxed'. Perhaps it is the use of > >the explicit '-u nobody'? I don't do that on > >my system, which causes Zope to run as nobody implicitly. > > > >(When started as root, unless told otherwise, zope will switch to nobody). > > > >Try running without the 'u nobody switch, and see what happens. Just out of > >curiousity. > > No difference. > > I think the point is that Zope does not make any initgroups(3) calls; > this will be a problem if the particular system needs it. > > I have two such systems: > > Linux 2.2.16 + glibc-2.1.2 > NetBSD 1.4 ... > Under this hypothesis, my question is how could _your_ system work? > Why is it that you don't have the original primary gid lingering in > the supplemental list? Not sure. Here is my setup: glibc 2.1.3 Kernel 2.2.15 heavilly modified Redhat 6.2 base. Perhaps it is the kernel? I also have a 2.2.16 (2.1.3 glibc) kernelled machine which exhibits the behavior you see on yours.. I can try it on a 2.2.4test6 kernel too ... -- Do not meddle in the affairs of sysadmins, for they are easy to annoy, and have the root password. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
