[Bug 3702] sshd fork crashed when compiled with seccomp

Wed Jun 19 07:46:01 AEST 2024

https://bugzilla.mindrot.org/show_bug.cgi?id=3702

--- Comment #2 from Nikola <root at nixsum.net> ---
Yes, here are the results from what I understand.

sshd logs:

debug1: inetd sockets after dupping: 4, 4
debug3: process_channel_timeouts: setting 0 timeouts
debug3: channel_clear_timeouts: clearing
Connection from ::1 port 46784 on ::1 port 222 rdomain ""
debug1: Local version string SSH-2.0-OpenSSH_9.7
debug1: Remote protocol version 2.0, remote software version
OpenSSH_9.2p1 Raspbian-2+deb12u2
debug1: compat_banner: match: OpenSSH_9.2p1 Raspbian-2+deb12u2 pat
OpenSSH* compat 0x04000000
debug2: fd 4 setting O_NONBLOCK
debug3: ssh_sandbox_init: preparing seccomp filter sandbox
debug2: Network child is on pid 13980
debug3: preauth child monitor started
debug3: privsep user:group 103:65534 [preauth]
debug1: permanently_set_uid: 103/65534 [preauth]
debug3: ssh_sandbox_child_debugging: installing SIGSYS handler
[preauth]
debug3: ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth]
debug3: ssh_sandbox_child: attaching seccomp filter program [preauth]
debug1: monitor_read_log: child log fd closed
debug3: mm_request_receive: entering
debug1: do_cleanup
debug1: Killing privsep child 13980
debug3: oom_adjust_setup
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug2: fd 4 setting O_NONBLOCK
debug1: Bind to port 222 on 0.0.0.0.
Server listening on 0.0.0.0 port 222.
debug2: fd 5 setting O_NONBLOCK
debug3: sock_set_v6only: set socket 5 IPV6_V6ONLY
debug1: Bind to port 222 on ::.
Server listening on :: port 222.
debug3: fd 6 is not O_NONBLOCK
debug1: Forked child 13999.
debug3: send_rexec_state: entering fd = 9 config len 3153
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug3: oom_adjust_restore
debug1: Set /proc/self/oom_score_adj to 0
debug1: rexec start in 6 out 6 newsock 6 pipe 8 sock 9
debug1: inetd sockets after dupping: 4, 4
debug3: process_channel_timeouts: setting 0 timeouts
debug3: channel_clear_timeouts: clearing
Connection from ::1 port 37764 on ::1 port 222 rdomain ""
debug1: Local version string SSH-2.0-OpenSSH_9.7
debug1: Remote protocol version 2.0, remote software version
OpenSSH_9.2p1 Raspbian-2+deb12u2
debug1: compat_banner: match: OpenSSH_9.2p1 Raspbian-2+deb12u2 pat
OpenSSH* compat 0x04000000
debug2: fd 4 setting O_NONBLOCK
debug3: ssh_sandbox_init: preparing seccomp filter sandbox
debug2: Network child is on pid 14000
debug3: preauth child monitor started
debug3: privsep user:group 103:65534 [preauth]
debug1: permanently_set_uid: 103/65534 [preauth]
debug3: ssh_sandbox_child_debugging: installing SIGSYS handler
[preauth]
debug3: ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth]
debug3: ssh_sandbox_child: attaching seccomp filter program [preauth]
debug1: monitor_read_log: child log fd closed
debug3: mm_request_receive: entering
debug1: do_cleanup
debug1: Killing privsep child 14000

After more careful inspection, the kernel log seems to sometimes
indicate syscall "384" and at other times "20" when initiating an ssh
connection:

[ 5106.975827] audit: type=1326 audit(1718651226.051:2): auid=1000
uid=103 gid=65534 ses=8 pid=8620 comm="sshd"
exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=384
compat=1 ip=0xf7a4d330 code=0x0
[ 5159.653285] audit: type=1326 audit(1718651278.730:3): auid=1000
uid=103 gid=65534 ses=8 pid=8651 comm="sshd"
exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=384
compat=1 ip=0xf74bd330 code=0x0
[ 5332.463045] audit: type=1326 audit(1718651451.531:4): auid=1000
uid=103 gid=65534 ses=8 pid=8711 comm="sshd"
exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=384
compat=1 ip=0xf744d330 code=0x0
[ 5435.206654] audit: type=1326 audit(1718651554.277:5): auid=1000
uid=103 gid=65534 ses=8 pid=8746 comm="sshd"
exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=20
compat=1 ip=0xf779252c code=0x0
[ 5483.156487] audit: type=1326 audit(1718651602.225:6): auid=1000
uid=103 gid=65534 ses=8 pid=8780 comm="sshd"
exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=20
compat=1 ip=0xf7b0252c code=0x0
[ 5930.773091] audit: type=1326 audit(1718652049.838:7): auid=1000
uid=103 gid=65534 ses=8 pid=8842 comm="sshd"
exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=384
compat=1 ip=0xf749d330 code=0x0
[ 6229.482998] audit: type=1326 audit(1718652348.541:8): auid=1000
uid=103 gid=65534 ses=8 pid=8934 comm="sshd"
exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=20
compat=1 ip=0xf743252c code=0x0
[ 6585.188845] audit: type=1326 audit(1718652704.242:9): auid=1000
uid=103 gid=65534 ses=8 pid=16018 comm="sshd"
exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=20
compat=1 ip=0xf7a0252c code=0x0
[ 6796.206919] audit: type=1326 audit(1718652915.250:10): auid=1000
uid=103 gid=65534 ses=8 pid=23058 comm="sshd"
exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=20
compat=1 ip=0xf7a8252c code=0x0

Although I'm not sure whether to trust that either.

Another thing I've noticed is that procfs shows processes performing a
syscall that is not implemented according to the header file and
multiple other sources I found online.

$ sudo cat /proc/1/syscall
252 0x4 0x18f69a8 0x8e 0xffffffff 0xffffffff 0x8e 0xffcce428 0xf75e7158
$ 
$ grep 252 /usr/include/asm-generic/unistd.h 
$ 
$ sudo cat /proc/13994/syscall
336 0x2425a08 0x2 0x0 0xffa76818 0x8 0x2 0xffa76528 0xf742297c
$ 
$ grep 336 /usr/include/asm-generic/unistd.h 
$

I don't know if this is due to some sort of incorrect mapping, I will
investigate further and see what I find.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.