Date: Thu, 18 Jan 2024 16:10:00 -0800 From: Alexander Richardson <arichardson@freebsd.org> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: Jessica Clarke <jrtc27@freebsd.org>, Shawn Webb <shawn.webb@hardenedbsd.org>, Cy Schubert <cy@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@freebsd.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@freebsd.org> Subject: Re: git: 0990136ed175 - main - kerberos5: Mitigate the possibility of using an old libcrypto Message-ID: <CA%2BZ_v8qm=ABncb69ZAxon%2ByUh=ye=9-aDvWRxqcNj8xtEqzroQ@mail.gmail.com> In-Reply-To: <20240118175553.9CC5E19B@slippy.cwsent.com> References: <202401181523.40IFNvXI077592@gitrepo.freebsd.org> <D89E55DF-846D-44FA-9287-0FFED7B08C2C@freebsd.org> <kicsvwuaptgfe2y5krflx35smstai6siea4rl7ycyrqdkawrxt@rqobtpgi257u> <973524D3-FCB2-47E1-B04F-BB42E18550C5@freebsd.org> <20240118175553.9CC5E19B@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BZ_v8qm=ABncb69ZAxon%2ByUh=ye=9-aDvWRxqcNj8xtEqzroQ>