Mailing List Archive

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

--- Comment #2 from Lacky <alacki93@gmail.com> ---
Created attachment 3592
--> https://bugzilla.mindrot.org/attachment.cgi?id=3592&action=edit
Log from sshd -D -ddd

--
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

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

--- Comment #3 from Lacky <alacki93@gmail.com> ---
Created attachment 3593
--> https://bugzilla.mindrot.org/attachment.cgi?id=3593&action=edit
Log from strace -f

--
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

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

--- Comment #4 from Lacky <alacki93@gmail.com> ---
(In reply to Darren Tucker from comment #1)

>
> If you build an sshd against and older set of headers that does not
> define __NR_clock_gettime64 then it will not be included, but that's
> because sshd has no way of knowing about it or what the syscall
> number is at compile time. I could imagine this biting you if you
> installed a new libc.so without recompiling sshd with the new
> headers.

Yes, but glibc doesn’t check it. They define syscalls in source code
(https://github.com/bminor/glibc/blob/glibc-2.34/sysdeps/unix/sysv/linux/arm/arch-syscall.h).

Now what happens on described test environment. Every time when sshd
tries to use clock_gettime from glibc you can find in strace something
like this:

4628 clock_gettime64(CLOCK_BOOTTIME, 0xbe8c1488) = -1 ENOSYS (Function
not implemented)
4628 clock_gettime(CLOCK_BOOTTIME, {tv_sec=247, tv_nsec=653301168}) =
0

Glibc first tries to use clock_gettime for 64 bit time. This fails
because kernel 4.14 doesn’t have support for this syscall (ENOSYS).
Then glibc tries to use classic clock_gettime. Usually this is not a
problem, but sshd uses seccomp. As you said sshd doesn’t add
clock_gettime64 as an allowed syscall to seccomp because it cannot find
it in kernel headers. Now let’s look at strace log. This entry means
that seccomp was initialized successfully for process with PID 4637:

4637 prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, {len=107,
filter=0x4ee324} <unfinished ...>
4637 <... prctl resumed>) = 0

After initialization of seccomp, process 4637 is killed when it tries
use unallowed clock_gettime64:

4637 clock_gettime64(CLOCK_BOOTTIME, <unfinished ...>
4637 <... clock_gettime64 resumed> <unfinished ...>) = ?
4637 +++ killed by SIGSYS +++
4628 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=4637,
si_uid=101, si_status=SIGSYS, si_utime=4, si_stime=0} ---
4628 kill(4637, SIGKILL)

From user perspective it looks like connection with server was closed
before any password prompt.

In attachments you can find log from sshd (run with “-D –ddd") and
strace (run with “-f”).

Temporary solution to fix this bugs are:
-Building OpenSSH without seccomp
-Building kernel without seccomp
-Patching glibc to remove clock_gettime64 syscall.

Disabling seccomp is the easiest workaround, but it decreases security
of sshd.

--
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

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

--- Comment #7 from Darren Tucker <dtucker@dtucker.net> ---
(In reply to Lacky from comment #6)
[...]
> Support for 64-bit time in 32 bit platforms has been added in kernel
> 5.1

The kernel version you're running should be irrelevant. If you were
running the same binary on a kernel that had 64bit time you'd have the
same problem because the headers don't have __NR_clock_gettime64 and
thus sshd didn't add it to the filter.

> > What distro are you using?
>
> This is Buildroot-based Linux (https://buildroot.org/).

Sorry, I don't think there's anything OpenSSH could do differently.
You've got a glibc that's making system calls that aren't in the
exported list of system calls. I think your buildroot should be
defining __NR_clock_gettime64 if its glibc is going to call it.

--
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