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

[bugzilla-daemon at mindrot.org]

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.