uid/gid issues on 2.6.26-rc2

uid/gid issues on 2.6.26-rc2

[Thibaut VARENE]

Hi pa-ckers

I'm sorry to be yet again just a whistle blower, I couldn't dig that
situation more yet but I'd like to raise awareness in case someone
else experiences the same symptoms. Also, what I'm seeing is a major
security flaw...

I'm running TOB on my A500 nosmp (when running SMP the timer code
borks gently). Randomly, the system seems to goof off regarding uids
and gids.

Typically, I'd ssh into the box as a regular user, and I end up with a
root prompt. Sometimes "w" will output nothing. dpkg will complain
about non-existing vlock group, etc.

Installing some package (with apt-get) I got the following message:
dpkg: syntax error: unknown group `vlock' in statoverride file
Trying again, it worked just fine

WRT ssh:

>From the remote host, I sometime got:
varenet@dogma:~$ ssh mkhppa3
ssh_exchange_identification: Connection closed by remote host

Trying again, I ended up with a root shell. Logging out and back in I
eventually got my own user's prompt.

Then, checking auth.log, I spotted a few very surprising things:

May 18 09:15:04 mkhppa3 sshd[1265]: Invalid user varenet from 147.215.7.200
May 18 09:15:04 mkhppa3 sshd[1265]: Failed none for invalid user
varenet from 147.215.7.200 port 58220 ssh2

May 18 20:50:04 mkhppa3 sshd[12623]: fatal: Privilege separation user
sshd does not exist
May 18 20:50:08 mkhppa3 sshd[12624]: Invalid user lucas from 147.215.7.12
May 18 20:50:08 mkhppa3 sshd[12624]: Failed none for invalid user
lucas from 147.215.7.12 port 59591 ssh2

(needless to say, user "sshd" exists locally and "varenet" and "lucas"
are on the ldap db. Plus, he could log in on a second attempt)

also:
May 18 12:17:01 mkhppa3 CRON[1302]: pam_unix(cron:account): could not
identify user (from getpwnam(root))

There's not much more evidence (couldn't find anything in other
logfiles or in dmesg...), but the box clearly didn't expose any such
symptom when running 2.6.22.14

HTH

T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/

Re: uid/gid issues on 2.6.26-rc2

[John David Anglin]

> I'm sorry to be yet again just a whistle blower, I couldn't dig that
> situation more yet but I'd like to raise awareness in case someone
> else experiences the same symptoms. Also, what I'm seeing is a major
> security flaw...
> 
> I'm running TOB on my A500 nosmp (when running SMP the timer code
> borks gently). Randomly, the system seems to goof off regarding uids
> and gids.

I've seen the same with various 2.6.25 32-bit builds.  Haven't seen
it with 64-bit builds.  However, the 64-bit builds haven't been particularly
stable (a few hpmcs).  That's why I still like 2.6.22.19 with Kyle's
compat_sys_getdents, and a few minor bug fixes.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: uid/gid issues on 2.6.26-rc2

[John David Anglin]

[-- Attachment #1: Type: text/plain, Size: 2371 bytes --]

On Sun, 18 May 2008, Thibaut VARENE wrote:

> Then, checking auth.log, I spotted a few very surprising things:
> 
> May 18 09:15:04 mkhppa3 sshd[1265]: Invalid user varenet from 147.215.7.200
> May 18 09:15:04 mkhppa3 sshd[1265]: Failed none for invalid user
> varenet from 147.215.7.200 port 58220 ssh2

I have seen this today testing 2.6.28 (32-bit UP).  The problem is also
present in postfix:

dave@hiauly6:/var/log$ less mail.err
Dec 27 12:45:41 hiauly6 postfix/sendmail[16726]: fatal: file /etc/postfix/main.cf: parameter mail_owner: unknown user name value: postfix

The only place this can occur is here:

static void check_mail_owner(void)
{
    struct passwd *pwd;

    if ((pwd = getpwnam(var_mail_owner)) == 0)
	msg_fatal("file %s/%s: parameter %s: unknown user name value: %s",
		  var_config_dir, MAIN_CONF_FILE,
		  VAR_MAIL_OWNER, var_mail_owner);

So, the problem is with getpwnam.  I don't see this with 2.6.22.19, so
the problem is likely a syscall issue.  These seem to be the syscalls
that directly relate to the getpwnam call:

open("/lib/libnss_files.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\0$\f\0\0\0004\0"..., 512) = 512
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 52324, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40b92000
mmap(0x40b9e000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb000) = 0x40b9e000
close(3)                                = 0
munmap(0x4051b000, 30889)               = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40006000
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
fcntl64(3, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)
_llseek(3, 0, [0], SEEK_CUR)            = 0
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap2(NULL, 1557, PROT_READ, MAP_SHARED, 3, 0) = 0x407ae000
_llseek(3, 1557, [1557], SEEK_SET)      = 0
munmap(0x407ae000, 1557)                = 0
close(3)                                = 0
exit_group(0)                           = ?

The failure appears random.  I think the problem occurs shortly after
forking.  It doesn't seem to be present in the 64-bit SMP 2.6.28 test
kernel that I'm testing.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

[-- Attachment #2: config-uly6.gz --]
[-- Type: application/x-gunzip, Size: 7828 bytes --]

Re: uid/gid issues on 2.6.26-rc2

[Helge Deller]

John David Anglin wrote:
> On Sun, 18 May 2008, Thibaut VARENE wrote:
> 
>> Then, checking auth.log, I spotted a few very surprising things:
>>
>> May 18 09:15:04 mkhppa3 sshd[1265]: Invalid user varenet from 147.215.7.200
>> May 18 09:15:04 mkhppa3 sshd[1265]: Failed none for invalid user
>> varenet from 147.215.7.200 port 58220 ssh2
> 
> I have seen this today testing 2.6.28 (32-bit UP).  The problem is also
> present in postfix:
> 
> dave@hiauly6:/var/log$ less mail.err
> Dec 27 12:45:41 hiauly6 postfix/sendmail[16726]: fatal: file /etc/postfix/main.cf: parameter mail_owner: unknown user name value: postfix
> 
> The only place this can occur is here:
> 
> static void check_mail_owner(void)
> {
>     struct passwd *pwd;
> 
>     if ((pwd = getpwnam(var_mail_owner)) == 0)
> 	msg_fatal("file %s/%s: parameter %s: unknown user name value: %s",
> 		  var_config_dir, MAIN_CONF_FILE,
> 		  VAR_MAIL_OWNER, var_mail_owner);
> 
> So, the problem is with getpwnam.  I don't see this with 2.6.22.19, so
> the problem is likely a syscall issue.  These seem to be the syscalls
> that directly relate to the getpwnam call:
> 
> open("/lib/libnss_files.so.2", O_RDONLY) = 3
> read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\0$\f\0\0\0004\0"..., 512) = 512
> fstat64(3, {st_mode=0, st_size=0, ...}) = 0
> mmap(NULL, 52324, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40b92000
> mmap(0x40b9e000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb000) = 0x40b9e000
> close(3)                                = 0
> munmap(0x4051b000, 30889)               = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40006000
> open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
> fcntl64(3, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)
> _llseek(3, 0, [0], SEEK_CUR)            = 0
> fstat64(3, {st_mode=0, st_size=0, ...}) = 0
> mmap2(NULL, 1557, PROT_READ, MAP_SHARED, 3, 0) = 0x407ae000
> _llseek(3, 1557, [1557], SEEK_SET)      = 0
> munmap(0x407ae000, 1557)                = 0
> close(3)                                = 0
> exit_group(0)                           = ?
> 
> The failure appears random.  I think the problem occurs shortly after
> forking.  It doesn't seem to be present in the 64-bit SMP 2.6.28 test
> kernel that I'm testing.

I think your assumption that it is related to fork might be correct.
I don't see the uid/gid issues, but instead very often when I ssh the first
time into the 32bit kernel of a parisc box this message:
[deller@halden deller]$ ssh c3000 -Xl root
ssh_exchange_identification: Connection closed by remote host

But the second try suddenly works:
[deller@halden deller]$ ssh c3000 -Xl root
Password:

It appears random as well, and since I think sshd forks itself, it could
be that we have some fork()-problem...

Helge

Re: uid/gid issues on 2.6.26-rc2

[John David Anglin]

> > The failure appears random.  I think the problem occurs shortly after
> > forking.  It doesn't seem to be present in the 64-bit SMP 2.6.28 test
> > kernel that I'm testing.
> 
> I think your assumption that it is related to fork might be correct.

I tried tracing what happens with sshd when a connection occurs but
I didn't learn much.  The uid/gid authentication uses compat mode on
the system where I see this problem.  It seems as if the authentication
setup is passed across the fork as I don't see any access to /etc/passwd
or /etc/shadow (password authentication is being used in this case).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)