Dear Debian folks,


Am Donnerstag, den 28.04.2011, 06:40 -0400 schrieb ALbert R. Valiev:

[…]

[…]

I am also experiencing this error using Squeeze with `openssh-server`
1:5.5p1-6.

        $ uname -m
        x86_64
        $ dpkg --print-architecture
        amd64
        $ dmesg
        […]
        [842739.686364] sshd[9922]: segfault at e57a30 ip 000000000044d915 sp 00007fffbe19f5a0 error 6 in sshd[400000+70000]
        [843416.720317] sshd[10624]: segfault at 183c9d0 ip 000000000044d915 sp 00007fffdd724170 error 6 in sshd[400000+70000]
        [843726.668196] sshd[10946]: segfault at 2257a30 ip 000000000044d915 sp 00007fff7023a6e0 error 6 in sshd[400000+70000]
        [844402.835133] sshd[11657]: segfault at 98d9d0 ip 000000000044d915 sp 00007ffffdaf9ac0 error 6 in sshd[400000+70000]
        [844712.069952] sshd[11974]: segfault at 16c9a30 ip 000000000044d915 sp 00007fffd96637b0 error 6 in sshd[400000+70000]
        […]

I can reproduce this with a username and entering a password. But it works using key authentication(?).

Please advise on how to debug this issue.


Thanks,

Paul

I did a quick gdb run on the system that Paul mentions.  I first ran "ssh
user@localhost" and then I ran gdb on the first of the two "sshd: unknown
[priv]" processes (which is the one that crashes).  After gdb was attached I
entered a random password (the test account in question didn't exist so no
password would get a login).

At the point of the crash gdb said:
Program received signal SIGTRAP, Trace/breakpoint trap.
0x000000000044e1b5 in ?? ()

After that I could use the "c" command in gdb to keep running and my ssh
client would ask me for another password (the expected action).  When I did
the same thing without gdb the sshd process would SEGV.

It seems that there is some debugging code enabled in ssh or it's libraries.

The problem that Paul reported only occurs on one system (I have not been able
to reproduce it on other AMD64 Xen DomU systems with a similar configuration).
It only occurs when SE Linux is in enforcing mode and when the default policy
is in use which doesn't permit the following access.  sshd aborts after the
below messages are logged.

I don't think that the problem Paul reported is a security problem and I
suspect that it may not be closely related to the original bug report.

type=AVC msg=audit(1315807424.338:39): avc:  denied  { unix_read unix_write }
for  pid=1363 comm="sshd" key=58236  scontext=system_u:system_r:sshd_t:s0-
s0:c0.c1023 tcontext=system_u:system_r:unconfined_t:s0-s0:c0.c1023 tclass=shm
type=SYSCALL msg=audit(1315807424.338:39): arch=c000003e syscall=29 success=no
exit=-131939286884392 a0=e37c a1=200048 a2=1b6 a3=0 items=0 ppid=627 pid=1363
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd"
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1315807424.338:40): avc:  denied  { unix_read unix_write }
for  pid=1363 comm="sshd" key=58771  scontext=system_u:system_r:sshd_t:s0-
s0:c0.c1023 tcontext=system_u:system_r:unconfined_t:s0-s0:c0.c1023 tclass=sem
type=SYSCALL msg=audit(1315807424.338:40): arch=c000003e syscall=64 success=no
exit=-131939286884392 a0=e593 a1=8 a2=1b6 a3=0 items=0 ppid=627 pid=1363
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd"
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=ANOM_ABEND msg=audit(1315807424.341:41): auid=4294967295 uid=0 gid=0
ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 pid=1363
comm="sshd" sig=11

These are shmget and semget.  Odd, since openssh has no code to call
those itself as far as I can see.  Can you get a backtrace from the
point where shmget is called?