extra groups passed by openssh - security issue?

[Martin Schulz]

Darren,
     thanks for trying to rep this.  See my replies below.
     From what you say the best option night be to  'upgrade away' these 
symptoms.
     I'll discuss trying out 3.8 and/or an upgraded Linux.
     Might also start trying this a variety of Linux versions.
     As far as we are concerned, it's only a minor anoyance.
     What worries me is any security implications this might have in 
general, however this will be limited to
     group level privs.

Darren Tucker wrote:

> Hi.
>     I installed daemontools-0.76 and was not able to reproduce this on 
> my box with OpenSSH 3.7.1p2 (RH9, 1 cpu, kernel 2.4.20-30.9).
>
> Martin Schulz wrote:
>
>> I would appreciate your opinion on a problem with sshd on Linux,
>> when running under daemontools supervise.
>> The configuration:
>> sshd version OpenSSH_3.7.1p2
>> Redhat Linux 2.4.20-8smp #1 SMP  i686
>> supervise / daemontools-0.76
>
>
> More information is needed:
> Did you compile OpenSSH yourself, and if so with what options?

Yes, ie. not me, but manually:
  $ ./configure --prefix=/usr/local --with-ssl-dir=/usr/local/

>
> In particular, are you using PAM?

Yes

> What's your account database (eg do you use NIS?)

files only - strace looks sensible, except that getgroups32 returns the 
extra groups.
(aliases / publickey use NIS+ also)

> Which Redhat release and have any patches been applied?

I think it's RH 8, unpatched.  Will check.

> What is the glibc version?

libc-2.3.2.so

> What does the script starting sshd contain?

#!/bin/bash
exec /usr/local/sbin/sshd -D

>
>
>> I see the following behavior regarding groups:
>> -bash-2.05b$ ssh mschulz at localhost id -Gn
>> id: cannot find name for group ID 201
>> id: cannot find name for group ID 2039
>> OA3  201 2039
>
> >
>
>> The group my account belongs to is OA3, groups 201 and 2039 do not 
>> exist..
>> (a normal login or su, and 'id -Gn' works as expected)
>
>
> What about running, eg, inetd/telnetd under daemontools?

Good point, however the box is supposed to be secure, but I'll try to 
get that checked.
What I did right now is adding a line 'id -Gn 
 >>/tmp/sshd_supervise_id.log' to the sshd
run script.
Then killed sshd, and I'm getting simply 'root', not even the other 
groups root belongs to.
Similarly, putting various id commands under 'supervise' control, did 
not result in any
extra groups.
That was unexpected, I was fully expecting the extra groups coming from 
'somewhere'.
I'll google for a kernel bug...

I've also tried variations of invoking su, never got anything different 
but the real groups back.

>
>
>> It turns out that when I run sshd standalone (debug), it works fine - 
>> only when run under the supervise command I see the strange extra 
>> groups.
>
>
> To clarify: running sshd as a stand-alone daemon (ie "sshd" with no 
> options) *and* with debugging (ie "sshd -ddd") both work correctly?

yes. It worked fine before put under supervise.  I tried -ddd and no 
problem either.

>
>
>> This is not related to SSH privilege separation, the install is 
>> correct and works fine with respect to the sshd privilege separation 
>> user. (I've
>
> > looked through the strace output).
>
>>
>> Between different user accounts, the problem occurs often with the 
>> exact same behavior,
>> but for some there is only one different extra group ID, or none at all.
>
>
> You always get the same behaviour with the same accounts?  What do the 
> users exhibiting these symptoms have in common?  Do those groups exist 
> in /etc/group or the gid field of /etc/passwd?

I haven't found a good pattern for that. The additional groups are 
'sticky', but I'll have to restart sshd during the week to see whether
that will change anything.
No, these groups don't exist (if they did, we might not have noticed 
this in the first place!). Not  in  /etc/group or /etc/passwd.
Furthermore several accounts  get the same extra  groups (201, 2039),  
root  gets a single extra group 200.

>
>> Is this a known problem?
>
>
> Not that I know of.
>
> [...]
>
Thanks again.

    Martin