[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-30 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #31 from JM  ---
Created attachment 3780
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3780&action=edit
bpf-filters-dumped.txt

printing the BPF filters at runtime

-- 
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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-30 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #30 from JM  ---
Created attachment 3779
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3779&action=edit
gdp-output.txt

gdb output before the errorring call to getpid

-- 
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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-30 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #29 from JM  ---
> Also, if you can catch the sandbox-violation in gdb, getting a disassembly of
> instructions around the violation would be instructive.

tl;dr reviewing disassembly of a `getpid` call that violates the
sandbox shows
  value `20` is the SYSCALL value used.
  That SYSCALL value is also in a `SC_ALLOW` BPF filter.

### DEBUG SESSION ###

 Debug Steps 

1. modify `Makefile` to build with debugging symbols:
   CFLAGS=-DDSANDBOX_SECCOMP_FILTER_DEBUG -ggdb -O0 ...
   LDFLAGS=-ggdb -O0 ...
2. In `sandbox-seccomp-filter.c`
   a. before the call to `prctl(PR_SET_SECCOMP, ...)`, I added a
`sleep(20)` and print `getpid()`
 
https://github.com/openssh/openssh-portable/blob/V_9_2_P1/sandbox-seccomp-filter.c#L438
  This prints the child process PID, and allows time to manually
attach the `gdb` to the new child process.
   b. Then added call to `raise(SIGINT)` so gdb will break just before
`prctl(PR_SET_SECCOMP, ...)`.
   c. After the call to `prctl(PR_SET_SECCOMP, ...)` I added a call to
`getpid()`
 
https://github.com/openssh/openssh-portable/blob/V_9_2_P1/sandbox-seccomp-filter.c#L445
  which will predictably invoke the sandbox violation. 
3. run the `sshd` program
   a. modify `sshd_config` to use port 55522
   b. build and run
  (set  -eux; make clean; make sshd; "$(realpath .)/sshd" -ddd
-f ./sshd_config)
6. run the client ssh to invoke the error
   ssh -v root@localhost -p 55522
7. when the `sshd` process sleeps for 20, attach `gdb`
gdb "--se=$(realpath ./sshd)" --pid=12345
8. in `gdb`
   a. `continue`
  it will break at `getpid` just after the `prctl` call
   b. `stepi` into the call to `getpid`

See code in file `bpf-filters-dumped.txt`

 Debug Result 

Here is that run of `gdb` controlling the child process.

The child process terminates with `SIGSYS, Bad system call` after call
to `getpid`
when `getpid` is called *after* the sandbox filters are set by call
`prctl(PR_SET_SECCOMP, ...)`
https://github.com/openssh/openssh-portable/blob/V_9_2_P1/sandbox-seccomp-filter.c#L439

$ gdb "--se=$(realpath ./sshd)" --pid=16588
...
(gdb) step
Single stepping until exit from function raise,
which has no line number information.
ssh_sandbox_child (box=0x1506010) at sandbox-seccomp-filter.c:648
648 if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER,
&preauth_program) == -1) {
(gdb) step
654 else if (nnp_failed) {
(gdb) step
662 pid_t pid_2 = getpid();
(gdb) stepi
0x008d62e4 in getpid@plt ()
(gdb) stepi
0x008d62e8 in getpid@plt ()
(gdb) stepi
0x008d62ec in getpid@plt ()
(gdb) stepi
0xf7c04800 in getpid () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) stepi
0xf7c04804 in getpid () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) disassemble
Dump of assembler code for function getpid:
   0xf7c04800 <+0>: push{r7}; (str r7, [sp,
#-4]!)
=> 0xf7c04804 <+4>: mov r7, #20
   0xf7c04808 <+8>: svc 0x
   0xf7c0480c <+12>:pop {r7}; (ldr r7, [sp],
#4)
   0xf7c04810 <+16>:bx  lr
End of assembler dump.
(gdb) stepi
0xf7c04808 in getpid () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) disassemble
Dump of assembler code for function getpid:
   0xf7c04800 <+0>: push{r7}; (str r7, [sp,
#-4]!)
   0xf7c04804 <+4>: mov r7, #20
=> 0xf7c04808 <+8>: svc 0x
   0xf7c0480c <+12>:pop {r7}; (ldr r7, [sp],
#4)
   0xf7c04810 <+16>:bx  lr
End of assembler dump.
(gdb) stepi

Program terminated with signal SIGSYS, Bad system call.
The program no longer exists.

See file `gdb-output.txt` for the full output.

### DUMP OF BPF FILTERS ###

Before the call to `prctl(PR_SET_SECCOMP, ...)`, I added a print of
`__NR_getpid`
https://github.com/openssh/openssh-portable/blob/V_9_2_P1/sandbox-seccomp-filter.c#L438

#ifdef __NR_getpgid
debug3("SC_ALLOW(__NR_getpgid=%d),", __NR_getpgid);
#endif

That code snippet is taken from the creation of the BPF filter defined
at compile-time.

  
https://github.com/openssh/openssh-portable/blob/V_9_2_P1/sandbox-seccomp-filter.c#L229

This prints `__NR_getpid=20` which means it is defined and BPF allowed.

debug3: SC_ALLOW(__NR_getpid=20), [preauth]

See file `bpf-filters-dumped.txt`.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-21 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #28 from JM  ---
> I'd like to reproduce this locally.  Could you please attach /etc/os-release 
> and the output of "dpkg -l" from the affected device?

Attached in `RPi4-dpkg-l.txt` and `RPi4.info`.

> Also, if you can catch the sandbox-violation in gdb, getting a disassembly of 
> instructions around the violation would be instructive.

I'll give it a shot.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-18 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #27 from Damien Miller  ---
Could you please provide this information so we can try to replicate it
ourselves:

(In reply to Darren Tucker from comment #11)
> I'd like to reproduce this locally.  Could you please attach
> /etc/os-release and the output of "dpkg -l" from the affected device?

Also my request from comment #25:

> Could you add try adding a similar printf+getpid+exit sequence to
> (say) the start of ssh-keygen.c, rerunning make and repeating the
> test using the resultant binary? You probably only need to do this
> on the rpi4

Also, if you can catch the sandbox-violation in gdb, getting a
disassembly of instructions around the violation would be instructive.

-- 
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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-17 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #26 from JM  ---
tl;dr a seccomp sandbox violation `20` occurs from a `read` (still).
  This is just a more detailed retelling of what was previously
discussed.
  Scroll to end for thoughts...

### problem specifics

Failed `read` in parent process

read(fd, s + pos, n - pos);

which is

read(5, '\014\221b', 4);

returns `0`.

Failed `read` will cause the following audit event (journalctl -f -x)

Dec 17 15:59:35 host1 kernel: audit: type=1326
audit(1702857575.824:3180): auid=4294967295 uid=107 gid=65534
ses=4294967295 pid=1920 comm="sshd"
exe="/root/Projects/openssh-9.2p1-WIP/sshd" sig=31 arch=4028
syscall=20 compat=1 ip=0xf7afd80c code=0x0

And the same when compiled with
`CFLAGS="-DDSANDBOX_SECCOMP_FILTER_DEBUG"`

Dec 17 22:37:50 pifuboo audit[10678]: SECCOMP auid=4294967295
uid=107 gid=65534 ses=4294967295 pid=10678 comm="sshd"
exe="/root/Projects/openssh-9.2p1-WIP/sshd" sig=31 arch=4028
syscall=20 compat=1 ip=0xf77de80c code=0x0
Dec 17 22:37:50 pifuboo audit[10678]: ANOM_ABEND auid=4294967295
uid=107 gid=65534 ses=4294967295 pid=10678 comm="sshd"
exe="/root/Projects/openssh-9.2p1-WIP/sshd" sig=31 res=1

The failed linux system call `20` is `epoll_create1` according to
`ausyscall`

$ ausyscall 20
epoll_create1

So the `read` at some point calls syscall `20`. See section "Summary
Thoughts" about this.

Here is the failed `read` call
https://github.com/openssh/openssh-portable/blob/V_9_2_P1/atomicio.c#L66
It is always the `read` call with values `fd=5`, `n=4`.
`read` returns `0`.
`errno` is not changed after `read` returns.

The stack just before the failed `read` call is:

#1  0x004701f8 in atomicio6
(f=f@entry=0xf7c65478 , fd=fd@entry=5, _s=0xfffeead8,
_s@entry=0xfffeead0, n=n@entry=4, cb=cb@entry=0x0,
cb_arg=cb_arg@entry=0x0)
at atomicio.c:67
#2  0x00470284 in atomicio
(f=f@entry=0xf7c65478 , fd=fd@entry=5,
_s=_s@entry=0xfffeead0, n=n@entry=4)
at atomicio.c:101
#3  0x00434520 in mm_request_receive
(sock=5, m=m@entry=0x4f2b88)
at monitor_wrap.c:149
#4  0x00431178 in monitor_read
(ssh=ssh@entry=0x4f3388, pmonitor=pmonitor@entry=0x4f2498,
ent=0x4e0114 , pent=pent@entry=0xfffeeb78)
at monitor.c:501
#5  0x00433b5c in monitor_child_preauth
(ssh=ssh@entry=0x4f3388, pmonitor=0x4f2498)
at monitor.c:301
#6  0x0040a388 in privsep_preauth
(ssh=0x4f3388)
at sshd.c:502
#7  main
(ac=, av=0x4e31a0)
at sshd.c:2240

(line numbers in `atomicio.c` slightly off due to insertion of
`raise(SIGINT);`)

The debug log from the start of client connection is:

debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 3296
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
process 32277 is executing new program:
/root/Projects/openssh-9.2p1/sshd
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/arm-linux-gnueabihf/libthread_db.so.1".
debug3: recv_rexec_state: entering fd = 5
debug3: ssh_msg_recv entering
debug3: recv_rexec_state: done
debug2: parse_server_config_depth: config rexec len 3296
debug3: rexec:14 setting Port 55222
debug3: rexec:22 setting HostKey
/root/Projects/openssh-9.2p1/ssh_host_ecdsa_key
debug3: rexec:23 setting HostKey
/root/Projects/openssh-9.2p1/ssh_host_ed25519_key
debug3: rexec:24 setting HostKey
/root/Projects/openssh-9.2p1/ssh_host_rsa_key
debug3: rexec:45 setting AuthorizedKeysFile .ssh/authorized_keys
debug3: rexec:113 setting Subsystem sftp   
/usr/libexec/sftp-server
debug1: sshd version OpenSSH_9.2, OpenSSL 1.1.1w  11 Sep 2023
debug1: private host key #0: ecdsa-sha2-nistp256
SHA256:7OUDaY7vmsaJPDkqGWPmdiw5kjY4bVSwCd94nJqT7/o
debug1: private host key #1: ssh-ed25519
SHA256:CuPO+bnbHMCkaNEybTHeYSjdNpiNdAlntO9gh0V9lxs
debug1: private host key #2: ssh-rsa
SHA256:ZYZLLhbWdOMFKDGw3pcn954Wz6RhwtDoI5WjJsZpXhk
debug1: inetd sockets after dupping: 3, 3
debug3: process_channel_timeouts: setting 0 timeouts
debug3: channel_clear_timeouts: clearing
Connection from 192.168.124.214 port 57930 on 192.168.124.214 port
55222 rdomain ""
debug1: Local version string SSH-2.0-OpenSSH_9.2
debug1: Remote protocol version 2.0, remote software version
OpenSSH_8.4p1 Raspbian-5+deb11u2
debug1: compat_banner: match: OpenSSH_8.4p1 Raspbian-5+deb11u2 pat
OpenSSH* compat 0x0400
debug2: fd 3 setting O_NONBLOCK
debug3: ssh_sandbox_init: preparing seccomp filter sandbox
[Detaching after fork from child process 32308]
debug2: Network child is on pid 32308
debug3: preauth child monitor started
debug3: privsep user:group 107:65534 [preauth]
debug1: permanently_s

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-11 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #25 from Damien Miller  ---
ok, so now I have no idea what is going wrong. Maybe there is something
in OpenSSH's compile flags that is messing this up.

Could you add try adding a similar printf+getpid+exit sequence to (say)
the start of ssh-keygen.c, rerunning make and repeating the test using
the resultant binary? You probably only need to do this on the rpi4

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-10 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #24 from JM  ---
> Could you try building and running this program. E.g.
> 
> $ cc -o syscall syscall.c 
> $ ./syscall
> $ strace -n ./syscall


Raspberry Pi 4 (RPi4), aarch64, Raspbian-Debian 11, (openssh 9.5p1
client thread aborts):

$ (set -eux; wget -q
"https://bugzilla.mindrot.org/attachment.cgi?id=3774"; -O syscall.c ; cc
-o syscall syscall.c ; ./syscall ; strace -n ./syscall )
+ wget -q 'https://bugzilla.mindrot.org/attachment.cgi?id=3774' -O
syscall.c
+ cc -o syscall syscall.c
+ ./syscall
__NR_getpid = 20
+ strace -n ./syscall
[  11] execve("./syscall", ["./syscall"], 0xffb2b5b4 /* 31 vars */)
= 0
[  45] brk(NULL)= 0x1ae5000
[ 122] uname({sysname="Linux", nodename="pifuboo", ...}) = 0
[  33] access("/etc/ld.so.preload", R_OK) = 0
[ 322] openat(AT_FDCWD, "/etc/ld.so.preload",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
[ 197] fstat64(3, {st_mode=S_IFREG|0644, st_size=54, ...}) = 0
[ 192] mmap2(NULL, 54, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) =
0xf7d7f000
[   6] close(3) = 0
[  85] readlink("/proc/self/exe", "/tmp/syscall", 4096) = 12
[ 322] openat(AT_FDCWD,
"/usr/lib/arm-linux-gnueabihf/libarmmem-v8l.so",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
[   3] read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\254\3\0\0004\0\0\0"...,
512) = 512
[ 197] fstat64(3, {st_mode=S_IFREG|0644, st_size=17708, ...}) = 0
[ 192] mmap2(NULL, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7d7d000
[ 192] mmap2(NULL, 81964, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7d3a000
[ 125] mprotect(0xf7d3e000, 61440, PROT_NONE) = 0
[ 192] mmap2(0xf7d4d000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0xf7d4d000
[   6] close(3) = 0
[  91] munmap(0xf7d7f000, 54)   = 0
[ 322] openat(AT_FDCWD, "/etc/ld.so.cache",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
[ 197] fstat64(3, {st_mode=S_IFREG|0644, st_size=63463, ...}) = 0
[ 192] mmap2(NULL, 63463, PROT_READ, MAP_PRIVATE, 3, 0) =
0xf7d2a000
[   6] close(3) = 0
[ 322] openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libc.so.6",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
[   3] read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\0y\1\0004\0\0\0"...,
512) = 512
[ 197] fstat64(3, {st_mode=S_IFREG|0755, st_size=1315688, ...}) = 0
[ 192] mmap2(NULL, 1385020, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7bd7000
[ 125] mprotect(0xf7d15000, 61440, PROT_NONE) = 0
[ 192] mmap2(0xf7d24000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13d000) = 0xf7d24000
[ 192] mmap2(0xf7d27000, 8764, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7d27000
[   6] close(3) = 0
[983045] set_tls(0xf7d7df80)= 0
[ 125] mprotect(0xf7d24000, 8192, PROT_READ) = 0
[ 125] mprotect(0xf7d4d000, 4096, PROT_READ) = 0
[ 125] mprotect(0x2, 4096, PROT_READ) = 0
[ 125] mprotect(0xf7d81000, 4096, PROT_READ) = 0
[  91] munmap(0xf7d2a000, 63463)= 0
[ 197] fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0),
...}) = 0
[  45] brk(NULL)= 0x1ae5000
[  45] brk(0x1b06000)   = 0x1b06000
[   4] write(1, "__NR_getpid = 20\n", 17__NR_getpid = 20
) = 17
[  20] getpid() = 21435
[ 248] exit_group(0)= ?
[ 248] +++ exited with 0 +++

Raspberry Pi 3 (RPi3), armv7l, Raspbian Debian 11, (openssh 9.5p1 runs
okay):

$ (set -eux; wget -q
"https://bugzilla.mindrot.org/attachment.cgi?id=3774"; -O syscall.c ; cc
-o syscall syscall.c ; ./syscall ; strace -n ./syscall )
+ wget -q 'https://bugzilla.mindrot.org/attachment.cgi?id=3774' -O
syscall.c
+ cc -o syscall syscall.c
+ ./syscall
__NR_getpid = 20
+ strace -n ./syscall
[  11] execve("./syscall", ["./syscall"], 0x7eab2584 /* 30 vars */)
= 0
[  45] brk(NULL)= 0x1435000
[ 192] mmap2(NULL, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76fa5000
[  33] access("/etc/ld.so.preload", R_OK) = 0
[ 322] openat(AT_FDCWD, "/etc/ld.so.preload",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
[ 197] fstat64(3, {st_mode=S_IFREG|0644, st_size=54, ...}) = 0
[ 192] mmap2(NULL, 54, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) =
0x76fa4000
[   6] close(3) = 0
[  85] readlink("/proc/self/exe", "/tmp/syscall", 4096) = 12
[ 322] openat(AT_FDCWD,
"/usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
[   3] read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\254\3\0\0004\0\0\0"...,
512) = 512
[ 197] fstat64(3, {st_mode=S_IFREG|0644, st_size=17708, ...}) = 0
[ 192] mmap2(NULL

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-10 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #23 from Damien Miller  ---
i.e. run it on a platform that works and the one that doesn't

-- 
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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-10 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #22 from Damien Miller  ---
Created attachment 3774
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3774&action=edit
syscall dumper

Could you try building and running this program. E.g.

$ cc -o syscall syscall.c 
$ ./syscall
$ strace -n ./syscall 

This will tell you what the compiler thinks __NR_getpid is vs what the
actual syscall is.

-- 
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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-10 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #21 from JM  ---
A little more info about `__NR_getpid` and `__NR_epoll_create1` (not
sure if this is relevant but in case you were curious)

On RPi4 (has aborts)

$ grep -r -Ee '__NR_getpid|__NR_epoll_create1' -- /usr/include/
/usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_epoll_create1,
sys_epoll_create1)
/usr/include/asm-generic/unistd.h:#define __NR_getpid 172
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_getpid,
sys_getpid)
/usr/include/arm-linux-gnueabihf/bits/syscall.h:#ifdef
__NR_epoll_create1
/usr/include/arm-linux-gnueabihf/bits/syscall.h:# define
SYS_epoll_create1 __NR_epoll_create1
/usr/include/arm-linux-gnueabihf/bits/syscall.h:#ifdef __NR_getpid
/usr/include/arm-linux-gnueabihf/bits/syscall.h:# define SYS_getpid
__NR_getpid
/usr/include/arm-linux-gnueabihf/asm/unistd-eabi.h:#define
__NR_getpid (__NR_SYSCALL_BASE + 20)
/usr/include/arm-linux-gnueabihf/asm/unistd-eabi.h:#define
__NR_epoll_create1 (__NR_SYSCALL_BASE + 357)
/usr/include/arm-linux-gnueabihf/asm/unistd-oabi.h:#define
__NR_getpid (__NR_SYSCALL_BASE + 20)
/usr/include/arm-linux-gnueabihf/asm/unistd-oabi.h:#define
__NR_epoll_create1 (__NR_SYSCALL_BASE + 357)

On RPi3 (runs okay)

$ grep -r -Ee '__NR_getpid|__NR_epoll_create1' -- /usr/include/
/usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_epoll_create1,
sys_epoll_create1)
/usr/include/asm-generic/unistd.h:#define __NR_getpid 172
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_getpid,
sys_getpid)
/usr/include/arm-linux-gnueabihf/bits/syscall.h:#ifdef
__NR_epoll_create1
/usr/include/arm-linux-gnueabihf/bits/syscall.h:# define
SYS_epoll_create1 __NR_epoll_create1
/usr/include/arm-linux-gnueabihf/bits/syscall.h:#ifdef __NR_getpid
/usr/include/arm-linux-gnueabihf/bits/syscall.h:# define SYS_getpid
__NR_getpid
/usr/include/arm-linux-gnueabihf/asm/unistd-oabi.h:#define
__NR_getpid (__NR_SYSCALL_BASE + 20)
/usr/include/arm-linux-gnueabihf/asm/unistd-oabi.h:#define
__NR_epoll_create1 (__NR_SYSCALL_BASE + 357)
/usr/include/arm-linux-gnueabihf/asm/unistd-eabi.h:#define
__NR_getpid (__NR_SYSCALL_BASE + 20)
/usr/include/arm-linux-gnueabihf/asm/unistd-eabi.h:#define
__NR_epoll_create1 (__NR_SYSCALL_BASE + 357)

On NanoPi NEO3 (runs okay)

$ grep -r -Ee '__NR_getpid|__NR_epoll_create1' -- /usr/include/
/usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_epoll_create1,
sys_epoll_create1)
/usr/include/asm-generic/unistd.h:#define __NR_getpid 172
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_getpid,
sys_getpid)
/usr/include/aarch64-linux-gnu/bits/syscall.h:#ifdef
__NR_epoll_create1
/usr/include/aarch64-linux-gnu/bits/syscall.h:# define
SYS_epoll_create1 __NR_epoll_create1
/usr/include/aarch64-linux-gnu/bits/syscall.h:#ifdef __NR_getpid
/usr/include/aarch64-linux-gnu/bits/syscall.h:# define SYS_getpid
__NR_getpid

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-10 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #20 from JM  ---
Created attachment 3773
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3773&action=edit
NanoPi-dpkg-l.txt

-- 
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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-10 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #19 from JM  ---
Created attachment 3772
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3772&action=edit
RPi4.info

-- 
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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-10 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #18 from JM  ---
Created attachment 3771
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3771&action=edit
RPi3.info

-- 
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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-10 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #17 from JM  ---
Created attachment 3770
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3770&action=edit
NanoPi_NEO3.info

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-10 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #16 from JM  ---
Created attachment 3769
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3769&action=edit
RPi3-dpkg-l.txt

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-10 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #15 from JM  ---
Created attachment 3768
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3768&action=edit
RPi4-dpkg-l.txt

-- 
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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-10 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #14 from JM  ---
Created attachment 3767
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3767&action=edit
config-9.2p1.h

-- 
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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-10 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #13 from JM  ---
Created attachment 3766
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3766&action=edit
config-9.1p1.h

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-10 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #12 from JM  ---
tl;dr compiles and runs okay on a Raspberry Pi3 and NanoPi NEO3 running
similar OS

For comparison, I've included three similar, not the same, platforms:
- Raspberry Pi 4 (RPi4) (aarch64) (Raspbian) on which this bug report
originated
- Raspberry Pi 3 (RPi3) (armv7l) (Raspbian) on which openssh 9.5p1 runs
fine (client can login, no thread aborts)
- NanoPi NEO3 Rockchip RK3288 (aarch64) (Debian) on which openssh 9.5p1
runs fine (client can login, no thread aborts)

I attached three ".info" files with various dumps of info about each
system.

To be clearer about the OS, I'm using the DietPI-managed distribution
of Raspbian (for Raspberry Pis) or Debian (for NanoPi)
(https://dietpi.com/).

> JM: what compiler are you using?

On RPi4 (has aborts)

$ cc --version
cc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110

On RPi3 (runs okay)

$ cc --version
cc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110

On NanoPi NEO3 (runs okay)

$ cc --version
cc (Debian 10.2.1-6) 10.2.1 20210110

On RPi4 (has aborts)

$ grep -r -E '__NR.*20$' /usr/include
/usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20
/usr/include/asm-generic/unistd.h:#define __NR_sched_getscheduler
120
/usr/include/asm-generic/unistd.h:#define __NR_clone 220
/usr/include/asm-generic/unistd.h:#define __NR_semtimedop_time64
420

$ grep -E NR.*getpid /usr/include/asm-generic/unistd.h
#define __NR_getpid 172
__SYSCALL(__NR_getpid, sys_getpid)

On RPi3 (runs okay)

$ grep -r -E '__NR.*20$' /usr/include
/usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20
/usr/include/asm-generic/unistd.h:#define __NR_sched_getscheduler
120
/usr/include/asm-generic/unistd.h:#define __NR_clone 220
/usr/include/asm-generic/unistd.h:#define __NR_semtimedop_time64
420

$ grep -E NR.*getpid /usr/include/asm-generic/unistd.h
#define __NR_getpid 172
__SYSCALL(__NR_getpid, sys_getpid)

On NanoPi NEO3 (runs okay)

$ grep -r -E '__NR.*20$' /usr/include
/usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20
/usr/include/asm-generic/unistd.h:#define __NR_sched_getscheduler
120
/usr/include/asm-generic/unistd.h:#define __NR_clone 220
/usr/include/asm-generic/unistd.h:#define __NR_semtimedop_time64
420

$ grep -E NR.*getpid /usr/include/asm-generic/unistd.h
#define __NR_getpid 172
__SYSCALL(__NR_getpid, sys_getpid)

> which a test program confirms:

Results from RPi4 (has aborts), using the same `test.c` source code
show above.

$ cc test.c
$ ./a.out
__NR_epoll_create1 357
__NR_getpid 20

On RPi3 (runs okay) same results:

$ cc test.c
$ ./a.out
__NR_epoll_create1 357
__NR_getpid 20

On NanoPi NEO3 (runs okay) differs:

$ cc test.c
$ ./a.out
__NR_epoll_create1 20
__NR_getpid 172

> Another thing that might be interesting is to compare config.h
> and the output of configure from 9.1p1 with those of 9.2p1 and
> see if anything unexpectedly changed.

Compared on the RPi4 (has aborts) of 9.1p1 and 9.2p1:

$ diff -d -B -W 80 -y --suppress-common-lines -- config-9.1p1.h
config-9.2p1.h
#define DISABLE_WTMPX 1   | /* #undef DISABLE_WTMPX */
#define HAVE_DECL_MEMMEM 0| #define HAVE_DECL_MEMMEM 1
/* #undef HAVE_SIGHANDLER_T */| #define HAVE_SIGHANDLER_T 1
  > /* sockaddr_in has sin_len
*/
  > /* #undef SOCK_HAS_LEN */
#define USER_PATH "/usr/bin:/bin:/usr | #define USER_PATH
"/usr/bin:/bin:/usr

Attached both config.h files from RPi4; `config-9.1p1.h`,
`config-9.2p1.h`.

> Could you please attach /etc/os-release and the output of "dpkg -l"
> from the affected device?

Attached in `RPi4-dpkg-l.txt` and `RPi4.info`.

> My guess would be something in libcrypto, in which case
> configuring --without-openssl and retesting would be a good indicator).

Tried `--without-openssl` on RPi4 using 9.5p1. Same error occurs.

$ make clean
$ ./configure --prefix=/opt/openssh-9.5p1-noopenssl
--without-openssl
$ make
$ make install

---

In case anyone is curious, general installation steps are taken from my
gist https://gist.github.com/jtmoon79/745e6df63dd14b9f2d17a662179e953a

--James T Moon (https://github.com/jtmoon79/)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-05 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #11 from Darren Tucker  ---
I'd like to reproduce this locally.  Could you please attach
/etc/os-release and the output of "dpkg -l" from the affected device?

-- 
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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-04 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #10 from Darren Tucker  ---
(In reply to Damien Miller from comment #9)
> It's likely that something is trying to use the epoll(3) API.
> OpenSSH itself doesn't use epoll, so it's likely to be something in
> libc, libcrypto or another library.

That's possible.  I checked /etc/os-release on my device, and it's
stock Debian not Raspbian.   My guess would be something in libcrypto,
in which case configuring --without-openssl and retesting would be a
good indicator).

-- 
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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-04 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #9 from Damien Miller  ---
hmm, it looks like I might have been wrong with the syscall number:

> [djm@djm linux]$ grep ' 20$' include/uapi/asm-generic/unistd.h
> #define __NR_epoll_create1 20

It's likely that something is trying to use the epoll(3) API. OpenSSH
itself doesn't use epoll, so it's likely to be something in libc,
libcrypto or another library.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-03 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #8 from Darren Tucker  ---
Created attachment 3765
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3765&action=edit
config.h from 9.2p1 working on rpi4

here's the configure output and config.h from my working system for
comparison.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-03 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #7 from Darren Tucker  ---
Created attachment 3764
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3764&action=edit
configure output from 9.2p1 working on rpi4

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-03 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #6 from Darren Tucker  ---
JM: what compiler are you using?

Another thing that might be interesting is to compare config.h and the
output of configure from 9.1p1 with those of 9.2p1 and see if anything
unexpectedly changed.

-- 
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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-03 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #5 from Darren Tucker  ---
(In reply to Damien Miller from comment #4)
> This is the details of the sandbox violation:
> 
> > ssh_sandbox_violation: unexpected system call (arch:0x4028,syscall:20 @ 
> > 0xf7ba380c
> 
> syscall 20 is getpid:
> 
> > [djm@djm linux]$ grep 'NR.* 20$' arch/arm64/include/asm/unistd32.h
> > #define __NR_getpid 20

That's not what it is on my rpi4.  I think that's for 32bit ARM.

$ uname -a
Linux hostname 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST
2023 aarch64 GNU/Linux
$ grep -r -E '__NR.*20$' /usr/include
/usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20

$ grep -E NR.*getpid /usr/include/asm-generic/unistd.h
#define __NR_getpid 172

which a test program confirms:

$ cat test.c
#include 
#include 
int main(void)
{
printf("__NR_epoll_create1 %d\n", __NR_epoll_create1);
printf("__NR_getpid %d\n", __NR_getpid);
}
$ cc test.c && ./a.out
__NR_epoll_create1 20
__NR_getpid 172

Testing on a 32bit arm, that is indeed 20:
$ uname -a
Linux hostname 5.16.10-bone14 #1bullseye PREEMPT Tue Feb 22 00:07:39
UTC 2022 armv7l GNU/Linux

$ cc test.c && ./a.out
__NR_epoll_create1 357
__NR_getpid 20

So perhaps the problem here is that either it's picking up 32bit vs
64bit headers, or that the binary is some kind of 32bit compatibility
mode but the sandbox is expecting the 64bit syscalls.

-- 
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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-03 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

Damien Miller  changed:

   What|Removed |Added

 CC||d...@mindrot.org

--- Comment #4 from Damien Miller  ---
This is the details of the sandbox violation:

> ssh_sandbox_violation: unexpected system call (arch:0x4028,syscall:20 @ 
> 0xf7ba380c

syscall 20 is getpid:

> [djm@djm linux]$ grep 'NR.* 20$' arch/arm64/include/asm/unistd32.h
> #define __NR_getpid 20

but getpid is allowed by the sshd sandbox policy:

> [djm@djm openssh]$ grep -A1 getpid sandbox-seccomp-filter.c
> #ifdef __NR_getpid
>   SC_ALLOW(__NR_getpid),
> #endif

However, this only works in __NR_getpid is defined in a system header
than that header is correctly picked up during sshd's compilation. If
your system headers are messed up then sshd won't pick up the correct
syscall number and sandbox violations will occur.

You could try attaching ./configure output and config.h (please don't
paste them inline), which might help, but I suspect that the root cause
is going that your system headers are messed up in some way.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

2023-12-02 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

JM  changed:

   What|Removed |Added

Summary|server thread aborts during |server thread aborts during
   |client login after  |client login after
   |receiving SSH2_MSG_KEXINIT  |receiving SSH2_MSG_KEXINIT
   ||due to
   ||ssh_sandbox_violation

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT

2023-12-02 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #3 from JM  ---
Created attachment 3763
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3763&action=edit
full formatted output of prctl(PR_SET_SECCOMP, ...)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT

2023-12-02 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #2 from JM  ---
tl;dr `strace` reveals error
`"\0\0\0c\0\0\0\1\0\0\0\0\0\0\0Wssh_sandbox_violation: unexpected
system call (arch:0x4028,syscall:20 @ 0xf7ba380c)"`
in response to a very large `prctl` Linux function call. (skip to the
end to see)

> try 9.5p1, 

Per my prior comment, I have tried 9.5p1. I tried 9.1p1 to 9.5p1. Only
9.1p1 didn't have this bug.

> I'd suggest building with -DSANDBOX_SECCOMP_FILTER_DEBUG to get additional 
> debugging on what's failing

I tried this with 9.5p1.

Built with the flag `DSANDBOX_SECCOMP_FILTER_DEBUG`

CFLAGS="-DDSANDBOX_SECCOMP_FILTER_DEBUG" ./configure
--prefix=/opt/openssh-9.5p1
make
make install

I could see in the output from `make` echoing the `cc` commands the
`-DSANDBOX_SECCOMP_FILTER_DEBUG` being passed, e.g.

cc -DSANDBOX_SECCOMP_FILTER_DEBUG -pipe
-Wno-error=format-truncation -Wall -Wpointer-arith -Wuninitialized
-Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess
-Wno-pointer-sign -Wno-unused-result -Wimplicit-fallthrough
-Wmisleading-indentation -fno-strict-aliasing -D_FORTIFY_SOURCE=2
-ftrapv -fno-builtin-memset -fstack-protector-strong   -fPIC -I. -I..
-I. -I./..  -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE
-D_GNU_SOURCE -DHAVE_CONFIG_H -c bindresvport.c

(so it looks like I passed `-DSANDBOX_SECCOMP_FILTER_DEBUG` correctly)

I added to /opt/openssh-9.5p1/etc/sshd_config

LogLevel DEBUG3

Then I ran `tail -f /var/log/auth.log` on the server.

Then I ran `strace sshd`, e.g.

strace --follow-forks --output-separately -o /tmp/sshd-9.5p1.out --
/opt/openssh-9.5p1/sbin/sshd -D

Elsewhere, login with an ssh client. The connection fails at the same
`debug1: SSH2_MSG_KEXINIT sent`. The `auth.log` has messages:

2023-12-02T20:01:24.242176-08:00 host1 sshd[5905]: debug3: fd 5 is
not O_NONBLOCK
2023-12-02T20:01:24.242601-08:00 host1 sshd[5905]: debug1: Forked
child 5951.
2023-12-02T20:01:24.242819-08:00 host1 sshd[5905]: debug3:
send_rexec_state: entering fd = 8 config len 3236
2023-12-02T20:01:24.243968-08:00 host1 sshd[5951]: debug3:
oom_adjust_restore
2023-12-02T20:01:24.244254-08:00 host1 sshd[5905]: debug3:
ssh_msg_send: type 0
2023-12-02T20:01:24.244408-08:00 host1 sshd[5905]: debug3:
send_rexec_state: done
2023-12-02T20:01:24.244559-08:00 host1 sshd[5951]: debug1: Set
/proc/self/oom_score_adj to 0
2023-12-02T20:01:24.244726-08:00 host1 sshd[5951]: debug1: rexec
start in 5 out 5 newsock 5 pipe 7 sock 8
2023-12-02T20:01:24.268631-08:00 host1 sshd[5951]: debug1: inetd
sockets after dupping: 4, 4
2023-12-02T20:01:24.269001-08:00 host1 sshd[5951]: debug3:
process_channel_timeouts: setting 0 timeouts
2023-12-02T20:01:24.269321-08:00 host1 sshd[5951]: debug3:
channel_clear_timeouts: clearing
2023-12-02T20:01:24.269677-08:00 host1 sshd[5951]: Connection from
10.0.1.2 port 42270 on 192.168.1.2 port 2234 rdomain ""
2023-12-02T20:01:24.269973-08:00 host1 sshd[5951]: debug1: Local
version string SSH-2.0-OpenSSH_9.5
2023-12-02T20:01:24.270263-08:00 host1 sshd[5951]: debug1: Remote
protocol version 2.0, remote software version OpenSSH_8.4p1
Debian-5+deb11u2
2023-12-02T20:01:24.270561-08:00 host1 sshd[5951]: debug1:
compat_banner: match: OpenSSH_8.4p1 Debian-5+deb11u2 pat OpenSSH*
compat 0x0400
2023-12-02T20:01:24.270834-08:00 host1 sshd[5951]: debug2: fd 4
setting O_NONBLOCK
2023-12-02T20:01:24.271097-08:00 host1 sshd[5951]: debug3:
ssh_sandbox_init: preparing seccomp filter sandbox
2023-12-02T20:01:24.271337-08:00 host1 sshd[5951]: debug2: Network
child is on pid 5952
2023-12-02T20:01:24.271573-08:00 host1 sshd[5951]: debug3: preauth
child monitor started
2023-12-02T20:01:24.272750-08:00 host1 sshd[5951]: debug3: privsep
user:group 107:65534 [preauth]
2023-12-02T20:01:24.273121-08:00 host1 sshd[5951]: debug1:
permanently_set_uid: 107/65534 [preauth]
2023-12-02T20:01:24.273369-08:00 host1 sshd[5951]: debug3:
ssh_sandbox_child_debugging: installing SIGSYS handler [preauth]
2023-12-02T20:01:24.273680-08:00 host1 sshd[5951]: debug3:
ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth]
2023-12-02T20:01:24.273938-08:00 host1 sshd[5951]: debug3:
ssh_sandbox_child: attaching seccomp filter program [preauth]
2023-12-02T20:01:24.274355-08:00 host1 sshd[5951]: debug1:
monitor_read_log: child log fd closed
2023-12-02T20:01:24.274650-08:00 host1 sshd[5951]: debug3:
mm_request_receive: entering
2023-12-02T20:01:24.274954-08:00 host1 sshd[5951]: debug1:
do_cleanup
2023-12-02T20:01:24.275832-08:00 host1 sshd[5951]: debug1: Killing
privsep child 5952
2023-12-02T20:01:24.241307-08:00 host1 sshd[5905]: debug3: fd 5 is
not O_NONBLOCK
2023-12-02T20:01:24.242538-08:00 host1 sshd[5905]: debug1: Forked
child 5951.
2023-12-02T20:01:24.242765-08:00 host1 sshd[5905]: debug3:
send_rexec_state: entering fd = 8 config len 3236
2023-12-02T20:01:24.242956-08:00

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT

2023-12-02 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

Darren Tucker  changed:

   What|Removed |Added

 CC||dtuc...@dtucker.net

--- Comment #1 from Darren Tucker  ---
(In reply to JM from comment #0)
[...]
> 2023-12-02T12:28:41.053381-08:00 host1 audit[3791]: SECCOMP
> auid=4294967295 uid=107 gid=65534 ses=4294967295 pid=3791
> comm="sshd" exe="/opt/openssh-9.2p1/sbin/sshd" sig=31 arch=4028
> syscall=20 compat=1 ip=0xf787080c code=0x0

This looks like a seccomp sandbox violation.  The first thing I'd
suggest is to try 9.5p1, because there were a couple of bugs fixed in
that specifically (bug#3512 and bug#3537).  There was also a thing
about RNG seeding, but that depended on an interaction between
different kernel and libc versions.

Failing that, I'd suggest building with -DSANDBOX_SECCOMP_FILTER_DEBUG
to get additional debugging on what's failing (but note that this
configuration is for debugging only and is not safe for production use)
and see what's in sshd's log.

FWIW I have an rpi4 with a very similar configuration to what you
describe ("Linux 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST
2023 aarch64 GNU/Linux") but was not able to reproduce the failure.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT

2023-12-02 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=3639

JM  changed:

   What|Removed |Added

 CC||jtm.moon.forum.user+mindrot
   ||@gmail.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs