Re: git: 0990136ed175 - main - kerberos5: Mitigate the possibility of using an old libcrypto

On Thu, 18 Jan 2024 at 10:06, Cy Schubert <Cy.Schubert@cschubert.com> wrote:
>
> In message <973524D3-FCB2-47E1-B04F-BB42E18550C5@freebsd.org>, Jessica
> Clarke w
> rites:
> > On 18 Jan 2024, at 17:35, Shawn Webb <shawn.webb@hardenedbsd.org> wrote:
> > >=20
> > > On Thu, Jan 18, 2024 at 05:29:47PM +0000, Jessica Clarke wrote:
> > >> On 18 Jan 2024, at 15:23, Cy Schubert <cy@FreeBSD.org> wrote:
> > >>>=20
> > >>> The branch main has been updated by cy:
> > >>>=20
> > >>> URL: =
> > https://cgit.FreeBSD.org/src/commit/?id=3D0990136ed1753ac7837206f9c5f4b83c=
> > cff6c405
> > >>>=20
> > >>> commit 0990136ed1753ac7837206f9c5f4b83ccff6c405
> > >>> Author:     Cy Schubert <cy@FreeBSD.org>
> > >>> AuthorDate: 2024-01-18 08:22:20 +0000
> > >>> Commit:     Cy Schubert <cy@FreeBSD.org>
> > >>> CommitDate: 2024-01-18 15:12:14 +0000
> > >>>=20
> > >>>   kerberos5: Mitigate the possibility of using an old libcrypto
> > >>>=20
> > >>>   By using the full library name (libcrypto.so.30) we avoid the =
> > exposure
> > >>>   of using an old, possibly vulnerable, library.
> > >>>=20
> > >>>   Reported by:            jrtc27
> > >>>   MFC after:              3 days
> > >>>   X-MFC with:             476d63e091c2
> > >>>   Fixes:                  476d63e091c2
> > >>> ---
> > >>> kerberos5/lib/libroken/fbsd_ossl_provider_load.c | 3 ++-
> > >>> 1 file changed, 2 insertions(+), 1 deletion(-)
> > >>>=20
> > >>> diff --git a/kerberos5/lib/libroken/fbsd_ossl_provider_load.c =
> > b/kerberos5/lib/libroken/fbsd_ossl_provider_load.c
> > >>> index 497b32124f96..2328041bc166 100644
> > >>> --- a/kerberos5/lib/libroken/fbsd_ossl_provider_load.c
> > >>> +++ b/kerberos5/lib/libroken/fbsd_ossl_provider_load.c
> > >>> @@ -5,6 +5,7 @@
> > >>> #include <openssl/provider.h>
> > >>>=20
> > >>> #if defined(OPENSSL_VERSION_MAJOR) && (OPENSSL_VERSION_MAJOR >=3D 3)
> > >>> +#define CRYPTO_LIBRARY "/lib/libcrypto.so.30"
> > >>=20
> > >> This still assumes the native ABI is in use, i.e. doesn=E2=80=99t =
> > account for
> > >> libcompat. Can we please just drop the directory, or if it=E2=80=99s =
> > really
> > >> needed for some reason at least handle the libcompat case?
> > >=20
> > > Using relative paths might carry a potential security risk if the
> > > LD_LIBRARY_PATH environment variable is set to an attacker-controlled
> > > directory.
> >
> > That=E2=80=99s true for direct linking too, yet we don=E2=80=99t =
> > hard-code everything
> > everywhere there. What=E2=80=99s special about dlopen?
>
> The reason for dlopen is to avoid building libcrypto during pre-build.
> libcrypto requires TARGET_ENDIANNESS to be defined. It is not defined when
> cross building from Linux or MacOS.
>
> TARGET_ENDIANNESS is defined by bsd.endian.mk, which state:
>
> # During bootstrapping on !FreeBSD OSes, we need to define some value.
> Short of
> # having an exhaustive list for all variants of Linux and MacOS we simply
> do not
> # set TARGET_ENDIANNESS and poison the other variables. They should be
> unused
> # during the bootstrap phases (apart from one place that's adequately
> protected
> # in bsd.compiler.mk) where we're building the bootstrap tools.
>
> To avoid this requirement during we let libroken build as usual during
> prebuild and load libcrypto, which is built later, thereby circumventing
> the prebuild requirement and avoiding redesigning our prebuild to define
> TARGET_ENDIANNESS for non-FreeBSD OSes.

If the problem is just missing TARGET_ENDIANESS, we can add something like
TARGET_ENDIANESS!=echo "__BYTE_ORDER__" | ${CC} -E -P -
for the bootstrapping case. But it seems to me that we just need to define the
L_ENDIAN/B_ENDIAN macros, can't that be done using the compiler-provided
macros (or endian.h) from some internal config header instead (or even
a new file injected via -include)?

Alex

>
> I don't think anyone here is prepared to redesign prebuild for this one
> single case. And, since Heimdal will be replaced by MIT, the requirement
> for our old Heimdal to work with OpenSSL 3.0 will disappear.
>
>
> --
> Cheers,
> Cy Schubert <Cy.Schubert@cschubert.com>
> FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
> NTP:           <cy@nwtime.org>    Web:  https://nwtime.org
>
>                         e^(i*pi)+1=0
>
>