openssh bugs - Mar 2021 - [Bug 3276] New: Missing SC_ALLOW(__NR_fstatat64) for ix86 + glibc 2.33 when OpenSSL not using getrandom()

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

            Bug ID: 3276
           Summary: Missing SC_ALLOW(__NR_fstatat64) for ix86 + glibc 2.33
                    when OpenSSL not using getrandom()
           Product: Portable OpenSSH
           Version: 8.5p1
          Hardware: ix86
                OS: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: bugs-a17 at moonlit-rail.com

Created attachment 3478
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3478&action=edit
Patch to fix this issue.

This is a follow on to #3260, opened as a new issue at Darren Tucker's
suggestion.  (I had emailed him, so will copy a rework of that email
here.)

I have a i686 Linux VM that I use for building 32-bit.  Upgraded to
glibc 2.33, and encountered SIGSYS as others reported.  The newest
8.5p1 with the fixes from #3260 works fine, if one uses a standard
configuration of OpenSSL as likely shipped by the OS distro.  But when
fixing a "feature" of OpenSSL that causes non-blocking reads to block,
one additional syscall is required in addition to those addressed by
#3260.  I'll upload a trivial 3-liner fix.

OpenSSL has a feature that allows user code to specify the source of
entropy used, usually /dev/random or /dev/urandom on *nix.  Recent
OpenSSL checks whether glibc supports the getrandom(2) call, and if so,
uses it; but in doing so, it ignores and bypasses the user's specified
source of entropy.  In particular, when reading random bytes in
non-blocking mode, getrandom() will block until the kernel's entropy
pool has "initialized."  On a VM in a quiet isolated network, that can
take up to several minutes in my experience, causing SSH connections to
a newly booted machine to hang for the duration.  (Other services, e.g.
www, smtp, are of course similarly affected.)

I "fixed" this locally by fooling OpenSSL's configure script to
ignore
the getrandom() call entirely, using only the entropy sources specified
by user code.  Works wonderfully!  But, it evidently uses one syscall
not used when getrandom() is called, and that is __NR_fstatat64.  When
OpenSSH is patched to allow that syscall, sshd will once again permit
incoming connections.

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

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

Darren Tucker <dtucker at dtucker.net> changed:

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

--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
Does the call need to succeed, or would allowing the call to fail with
EACCES be sufficient?  ie

SC_DENY(__NR_fstatat64), EACCES),

similar to the other *stat* calls in that file?

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |3270


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=3270
[Bug 3270] Tracking bug for 8.6 release
-- 
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.

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

Kris Karas <bugs-a17 at moonlit-rail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3478|0                           |1
        is obsolete|                            |

--- Comment #2 from Kris Karas <bugs-a17 at moonlit-rail.com> ---
Created attachment 3480
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3480&action=edit
Updated patch, seems to work fine

Interesting theory, to label a required syscall as a "deny". 
Counterintuitive, so I didn't try that before.

However, just tested the update, attached as a patch, and it works fine
as a deny.  Seems safer, though I'd be happier if I knew the odd
mechanics there.

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Darren Tucker <dtucker at dtucker.net> ---
Thanks for the report and patch.  It's been applied and will be in the
next release.

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

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

--- Comment #4 from Kris Karas <bugs-a17 at moonlit-rail.com> ---
Terrific.  Thanks.

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

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