openssh bugs - Oct 2022 - [Bug 3478] New: Default "kill" action of seccomp sandbox is fragile

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

            Bug ID: 3478
           Summary: Default "kill" action of seccomp sandbox is
fragile
           Product: Portable OpenSSH
           Version: v9.0p1
          Hardware: All
               URL: https://bugs.debian.org/991936
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: cjwatson at debian.org

Created attachment 3615
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3615&action=edit
Change seccomp sandbox default action to ENOSYS
>From time to time, glibc changes its syscall wrappers to make use of
new Linux kernel facilities.  The strategy it uses for this is often to
try more recently-introduced syscalls, but fall back to older ones if
it gets ENOSYS, allowing it to cope gracefully with running on older
kernel versions.

Unlike (as I understand it) OpenBSD's pledge(2), sandboxing using
Linux's seccomp inherently violates the abstraction layer of C library
calls to at least some extent, forcing programs that use it to keep
track of changes to the C library.  While OpenSSH has been doing a
reasonable job at keeping up with this, it's fragile and typically
reactive; I've had to update OpenSSH in Debian stable releases in the
past to keep up with new kernels, or sometimes edge cases on less
widely-used architectures.  (In the linked bug, Julian also points out
that it can cause issues when running older userspace versions in
containers or similar on top of newer host kernels, as you might expect
from this class of problem.)  I would like sshd to be less fragile
here.

The attached patch is one possible suggestion for making this less of a
problem in future.  It passes the regression tests here, but is
otherwise definitely in the nature of an RFC.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Colin Watson from comment #0)
> From time to time, glibc changes its syscall wrappers to make use of
> new Linux kernel facilities.  The strategy it uses for this is often
> to try more recently-introduced syscalls, but fall back to older
> ones if it gets ENOSYS, allowing it to cope gracefully with running
> on older kernel versions.
Arbitrarily failing syscalls that do not normally fail has been the
source of serious security vulnerabilities in the past (eg
CVE-2000-0506).  That's why the default action is "kill" instead
of
"fail" and others are considered on a case by case basis.
> it's fragile and typically reactive
You omitted "architecture dependent" :-)  Our CI tests on amd64, i386,
arm, arm64, mips, mipsel and riscv64 but it's impossible for us to
cover every architecture/kernel/glibc combination.
> sandboxing using
> Linux's seccomp inherently violates the abstraction layer of C
> library calls to at least some extent, forcing programs that use it
> to keep track of changes to the C library.
I think that's a pretty good argument that glibc should provide an
interface that is usable by applications that does not have that
layering violation.  Even just being able to specify the filters by
libc function name rather than syscall name would help a lot, however I
suspect doing that would be challenging given that the kernel and glibc
are developed independently.

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

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

--- Comment #2 from Colin Watson <cjwatson at debian.org> ---
(In reply to Darren Tucker from comment #1)
> Arbitrarily failing syscalls that do not normally fail has been the
> source of serious security vulnerabilities in the past (eg
> CVE-2000-0506).  That's why the default action is "kill"
instead of
> "fail" and others are considered on a case by case basis.
I don't think this is _not_ an issue, and I agree it requires care -
that's why I included the umask case - but I think we have more
problems the other way round.
> I think that's a pretty good argument that glibc should provide an
> interface that is usable by applications that does not have that
> layering violation.  Even just being able to specify the filters by
> libc function name rather than syscall name would help a lot,
> however I suspect doing that would be challenging given that the
> kernel and glibc are developed independently.
Sure, but there seems little appetite to do this with actually-existing
Linux and glibc (I certainly don't have time for that sort of
multi-year project), so where does that leave us?  Tracking syscall
minutiae forever doesn't seem appealing.

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

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

--- Comment #3 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Colin Watson from comment #2)
> (In reply to Darren Tucker from comment #1)
> > [...]security vulnerabilities 
>
> I don't think this is _not_ an issue, and I agree it requires care -
> that's why I included the umask case - but I think we have more
> problems the other way round.
Those fail closed and are (eventually) reported and fixed.  The
alternative fails open and risks becoming an exploit.
> > [fixing it in glibc]
> 
> Sure, but there seems little appetite to do this with
> actually-existing Linux and glibc (I certainly don't have time for
> that sort of multi-year project), so where does that leave us? 
> Tracking syscall minutiae forever doesn't seem appealing.
I don't have a good answer for that.

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
Created attachment 3640
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3640&action=edit
safer debugging for seccomp sandbox violations

One thing we could do it make it easier to debug seccomp sandbox
failures. Currently, these require a rebuild of OpenSSH and some
signal-handler unsafe code (though I think its impact is limited to
hung connections).

This tries to make the sandbox violation debugging signal handler safe
and AFAIK safe enough to keep enabled all the time. The only catch is
that it requires stderr attached as every other option (syslog, monitor
log socket) is either unavailable or requires signal handler unsafe
syscalls.

Example (inserting a random setuid() call into sshd.c):

[djm at djm openssh]$ sudo /home/djm/cvs/openssh/sshd -Dep2222
-oPidFile=none -fnone
Server listening on 0.0.0.0 port 2222.
Server listening on :: port 2222.
ssh_sandbox_violation: unexpected system call: arch:0xc000003e
syscall:0x69 addr:0x7f9ad54dc405

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

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

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
Created attachment 3641
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3641&action=edit
another version, logging via monitor

Here'e another version, it's a bit more complex but it preserves
logging via the usual path by implementing the log writing using
signal-handler safe code.

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3641|                            |ok?(dtucker at dtucker.net)
              Flags|                            |

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