libressl: crash in DES_fcrypt
libressl-2.6.2 is susceptible to an out-of-bounds read: #include int main(void) { char salt[3] = {0xf8, 0xd0, 0x00}; char out[32]; DES_fcrypt("foo", salt, out); } Place in libressl's fcrypt.c: x=ret[0]=((salt[0] == '\0')?'A':salt[0]); Eswap0=con_salt[x]<<2; // boom ASM:=> 0x777a6fa8 <+56>:movzbl (%rcx,%rdx,1),%ebp rcx = con_salt rdx = 0xfff8 Because salt[0] is -8, x will be 0xfff8 due to type promotion and conversion. con_salt[0xfff8] is then evaluted, which bombs out. openssl 1.1.x has it fixed (but 1.0.2l does not!) - their commit seems to be 6493e4801e9edbe1ad1e256d4ce9cd55c8aa2242 in https://github.com/openssl/openssl .
Re: LibreSSL 2.2.2 release
On Wednesday 2015-08-12 20:29, Mark Kettenis wrote: > >One possible reason to deviate from using the LibreSSL release version >would be if we want to continue to be a drop-in replacement for >OpenSSL. In that case continuing to adevrtise a reasonable OpenSSL >version number for openssl.pc, libcrypto.pc and libssl.pc might make >sense. Probably best to involve ports people in that decision though. The openssl API did not change very often. Many build recipes request "pkgconfig(libcrypto) >= 0.9.7" or >= 1.0.0 for example, which the libressl files satisfy thanks to their 2.x numbering (well, 35:0:0 also satisfies it, numerically).
Re: LibreSSL 2.2.2 release
On Tuesday 2015-08-11 03:39, Brent Cook wrote: > >> So I think all the .pc files in LibreSSL should simply use the LibreSSL >> version number (2.2.2) like the openssl.pc does. This does mean that >> checking >> for individual libraries in LibreSSL version 2.2.2 and older will probably >> busted, but such is life. Not sure how the colon-separated version strings >> interact with --atleast-version. Might be worth checking that out. > >The main exception I found was that ffmpeg encoded ABI rather than API >in its .pc files too, but your explanations make sense to me. Well, at least ffmpeg's liba* use the MMM [major.minor.micro] version, and thus '.' as a separator, rather than trying to stuff the libtool CRA [current:release:age] spec into the .pc file.
Re: LibreSSL 2.2.2 release
On Monday 2015-08-10 02:38, Brent Cook wrote: >> On Aug 9, 2015, at 10:07 AM, Jan Engelhardt wrote: >> >>> We have released LibreSSL 2.2.2, which will be arriving in the >>> LibreSSL directory of your local OpenBSD mirror soon. >> >> The .pc files in libressl-2.2.2 upset the package mechanisms at hand, in >> particular rpm, where ':' is used to denote the (ancient concept of) >> epochs. >> >> [ 99s] Invalid version (double separator ':'): 35:0:0: >> mingw32(pkg:libcrypto) = 35:0:0 >> [ 99s] mingw32(pkg:libssl) = 35:0:0 >> [ 99s] mingw32(pkg:libtls) = 6:0:0 >> [ 99s] mingw32(pkg:openssl) = 2.2.2 >> >> The version: field in .pc files is (still) supposed to be the >> package version number, not the ABI number, and this was not a problem >> in libressl <= 2.2.1. > >Thanks for the note, Jan. > >Right or wrong, I'm fairly certain the format has not changed any time >recently, e.g. here is the libtls .pc file from 2.2.1: So it turns out rpm does not consider it an error, just a warning (but it is the first time the warning showed up on the last screenful, the one paid most attention to). >I'm not so sure that this should be the package version number though. Can you >point to some further documentation here? pkg-config(1): "Version: This should be the most-specific-possible package version string." * x:0:0 is not specific enough, as it would not change when the ABI-API stays unmodified between two releases. * the observation that all other .pc files I happen to have installed on my machine right now (some 194) all match \d+(\.\d+)*
Re: LibreSSL 2.2.2 release
>We have released LibreSSL 2.2.2, which will be arriving in the >LibreSSL directory of your local OpenBSD mirror soon. The .pc files in libressl-2.2.2 upset the package mechanisms at hand, in particular rpm, where ':' is used to denote the (ancient concept of) epochs. [ 99s] Invalid version (double separator ':'): 35:0:0: mingw32(pkg:libcrypto) = 35:0:0 [ 99s] mingw32(pkg:libssl) = 35:0:0 [ 99s] mingw32(pkg:libtls) = 6:0:0 [ 99s] mingw32(pkg:openssl) = 2.2.2 The version: field in .pc files is (still) supposed to be the package version number, not the ABI number, and this was not a problem in libressl <= 2.2.1.
Re: LibreSSL 2.1.2 released
On Saturday 2014-12-13 00:08, Brent Cook wrote: >> On Dec 12, 2014, at 5:04 PM, Jan Engelhardt wrote: >> >> To solve that, simply add >> >> libcrypto_la_LDFLAGS = -no-undefined >> [same for libssl,libtls] >> >> Without this, the DLLs won't be produced. > >Thanks for the hint, will do! For reference, here is the full patch I needed. --- crypto/Makefile.am |2 +- crypto/bio/bss_log.c |4 ++-- ssl/Makefile.am |3 ++- tls/Makefile.am |3 ++- 4 files changed, 7 insertions(+), 5 deletions(-) Index: libressl-2.1.2/crypto/Makefile.am === --- libressl-2.1.2.orig/crypto/Makefile.am +++ libressl-2.1.2/crypto/Makefile.am @@ -8,7 +8,7 @@ lib_LTLIBRARIES = libcrypto.la EXTRA_DIST = VERSION -libcrypto_la_LDFLAGS = -version-info @LIBCRYPTO_VERSION@ +libcrypto_la_LDFLAGS = -version-info @LIBCRYPTO_VERSION@ -no-undefined libcrypto_la_LIBADD = libcompat.la libcompatnoopt.la libcrypto_la_CFLAGS = $(CFLAGS) $(USER_CFLAGS) libcrypto_la_CFLAGS += -DOPENSSL_NO_HW_PADLOCK Index: libressl-2.1.2/crypto/bio/bss_log.c === --- libressl-2.1.2.orig/crypto/bio/bss_log.c +++ libressl-2.1.2/crypto/bio/bss_log.c @@ -70,7 +70,7 @@ #include #include -#ifndef NO_SYSLOG +#if !defined(_WIN32) && !defined(NO_SYSLOG) static int slg_write(BIO *h, const char *buf, int num); static int slg_puts(BIO *h, const char *str); @@ -210,4 +210,4 @@ xcloselog(BIO* bp) closelog(); } -#endif /* NO_SYSLOG */ +#endif /* !WIN32 && !NO_SYSLOG */ Index: libressl-2.1.2/ssl/Makefile.am === --- libressl-2.1.2.orig/ssl/Makefile.am +++ libressl-2.1.2/ssl/Makefile.am @@ -4,8 +4,9 @@ lib_LTLIBRARIES = libssl.la EXTRA_DIST = VERSION -libssl_la_LDFLAGS = -version-info @LIBSSL_VERSION@ +libssl_la_LDFLAGS = -version-info @LIBSSL_VERSION@ -no-undefined libssl_la_CFLAGS = $(CFLAGS) $(USER_CFLAGS) +libssl_la_LIBADD = ../crypto/libcrypto.la libssl_la_SOURCES = bio_ssl.c libssl_la_SOURCES += d1_both.c Index: libressl-2.1.2/tls/Makefile.am === --- libressl-2.1.2.orig/tls/Makefile.am +++ libressl-2.1.2/tls/Makefile.am @@ -5,8 +5,9 @@ lib_LTLIBRARIES = libtls.la EXTRA_DIST = VERSION -libtls_la_LDFLAGS = -version-info @LIBTLS_VERSION@ +libtls_la_LDFLAGS = -version-info @LIBTLS_VERSION@ -no-undefined libtls_la_CFLAGS = $(CFLAGS) $(USER_CFLAGS) +libtls_la_LIBADD = ../ssl/libssl.la libtls_la_SOURCES = tls.c libtls_la_SOURCES += tls_client.c
Re: LibreSSL 2.1.2 released
With libressl 2.1.2, I observe: > ldd -r /usr/lib64/libtls.so.1 linux-vdso.so.1 (0x7ffe5462e000) libc.so.6 => /lib64/libc.so.6 (0x7ffe5405f000) /lib64/ld-linux-x86-64.so.2 (0x7ffe5463) undefined symbol: GENERAL_NAME_free (/usr/lib64/libtls.so.1) undefined symbol: X509_NAME_get_text_by_NID (/usr/lib64/libtls.so.1) undefined symbol: ASN1_STRING_length(/usr/lib64/libtls.so.1) undefined symbol: SSL_get_error (/usr/lib64/libtls.so.1) undefined symbol: OBJ_txt2nid (/usr/lib64/libtls.so.1) undefined symbol: sk_pop_free (/usr/lib64/libtls.so.1) undefined symbol: SSL_write (/usr/lib64/libtls.so.1) undefined symbol: SSLv23_client_method (/usr/lib64/libtls.so.1) undefined symbol: sk_value (/usr/lib64/libtls.so.1) [...] Is this intentional, or would you concur that libressl-2.1.2/tls/Makefile.am should get a libtls_la_LIBADD = ../ssl/libssl.la line? In addition, when building for mingw, there is a warning. libtool: link: warning: undefined symbols not allowed in x86_64-w64-mingw32 shared libraries To solve that, simply add libcrypto_la_LDFLAGS = -no-undefined [same for libssl,libtls] Without this, the DLLs won't be produced.
Re: LibreSSL 2.0.4 released
On Monday 2014-08-04 01:36, Bob Beck wrote: >We have released LibreSSL 2.0.4, which should be arriving n the >LibreSSL directory of an OpenBSD mirror near you very soon. > >This version includes more portability changes, as well as other work. >most noticable may be the deletion of the of the SRP code (which has >not been enabled in any LibreSSL release). Can you also provide .pc file(name)s that don't collide with openssl? That would make it a bit easier having both installed at the same time.
Re: Miscellaneous LibreSSL portability fixes
On Thursday 2014-07-17 00:02, Jonas 'Sortie' Termansen wrote: > >* The build system defaults --program-transform-name to the host triplet > when cross-compiling. It shouldn't do that as the library doesn't have > a target and is not a cross-compiler (as far as I know). It certainly > doesn't make sense to do when the library itself is being > cross-compiled. This also caused unexpected trouble during the man > page installation as the real man pages got installed under the > transformed name, but the hard links to the man pages wasn't > transformed and broke the build. The problem is not that there is a default transformation for cross compilers, but that the software package declares itself to be a cross utility. The fix is to replace all occurrences of "target" by "host". That is, AC_CANONICAL_TARGET -> AC_CANONICAL_HOST, $target -> $host, $target_os -> $host_os, and so on, in configure.ac and other build scripts in libressl.
Re: Miscellaneous LibreSSL portability fixes
On Thursday 2014-07-17 00:02, Jonas 'Sortie' Termansen wrote: > >* ioctl(FIONBIO) is used in a few files to make sockets non-blocking > rather than using fcntl to set the the standard O_NONBLOCK bit. The > files apps/s_client.c and apps/s_server.c should use BIO_socket_nbio() > instead of directly using BIO_socket_ioctl(). The bio/b_sock.c file > should implement BIO_shock_nbio() using fcntl, F_GETFL/F_SETFL and > O_NONBLOCK. There's likely a reason for that. O_NONBLOCK is not available in the mingw toolchain, which I take as an indicator that the Windows runtime does not know it either. However, FIONBIO _is_ available; the function call is along the lines of ioctlsocket(fd, ..FIONBIO..);
Re: Miscellaneous LibreSSL portability fixes
On Thursday 2014-07-17 00:02, Jonas 'Sortie' Termansen wrote: > >I ported libressl to my custom hobby OS and it has been a pleasant >experience. Nonetheless, I did run into some minor portability problems >that I wish to share: > >* apps/Makefile.am.tpl links libcrypto and libssl in the wrong order. > The libssl library depends on libcrypto and libcrypto doesn't depend > on libssl. >diff -Nur libressl-2.0.2/apps/Makefile.am libssl/apps/Makefile.am >--- libressl-2.0.2/apps/Makefile.am2014-07-16 05:25:52.0 +0200 >+++ libssl/apps/Makefile.am2014-07-16 13:26:55.425448073 +0200 >@@ -4,8 +4,8 @@ > > openssl_CFLAGS = $(USER_CFLAGS) > openssl_LDADD = $(PLATFORM_LDADD) >-openssl_LDADD += $(top_builddir)/crypto/libcrypto.la > openssl_LDADD += $(top_builddir)/ssl/libssl.la >+openssl_LDADD += $(top_builddir)/crypto/libcrypto.la If libssl depends on libcrypto, we should set libssl_la_LIBADD += ${top_builddir}/crypto/libcrypto.la in the first place for proper transitivity. (And then, openssl_LDADD becomes the dependency list just for openssl_SOURCES.)
Re: LibreSSL portable 2.0.2 released.
>We have release an update, LibreSSL 2.0.2 > >This release addresses the Linux forking and pid wrap issue reported >recently in the press. The newly-added /tests/asn1test fails to complete successfully under Linux when built as 32-bit object, in either a 32-bit userspace or on a multiarch. $ ./configure CFLAGS=-m32 LDFLAGS=-m32 && make -j4 check checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu [...] $ tests/asn1test FAIL: test 2 returned ASN1 length 340, want 349
Re: LibreSSL 2.0.1 released - installation extra_mode
On Monday 2014-07-14 20:34, Bob Beck wrote: >What problem are you trying to solve here. >> Pristine libtool does not pass -m 644, and default (GNU) install >> defaults to mode 755 when not specifying anything else. I am trying to figure out why OpenBSD would be patching libtool and adding +case " $install_prog " in +*[\\\ /]cp\ *) extra_mode=;; +*) extra_mode='-m 644';; +esac (in http://www.openbsd.org/cgi-bin/cvsweb/ports/devel/libtool/patches/patch-libltdl_config_ltmain_sh?rev=1.2;content-type=text/plain )
Re: LibreSSL 2.0.1 released - installation extra_mode
On Monday 2014-07-14 20:16, Toni Mueller wrote: >Hi Jan, > >On Sun, Jul 13, 2014 at 08:30:38PM +0200, Jan Engelhardt wrote: >> On Sunday 2014-07-13 13:07, Bob Beck wrote: >> >We have released an update, LibreSSL 2.0.1 >> >As noted before, we welcome feedback from the broader community. >> >> Something that I have noticed is that the shared libraries generated >> by the portable libressl tarball are installed to their final >> location (in DESTDIR) with odd mode 644. > >what's odd about this mode? On my Debian box, I have, for the OpenSSL >lib: >$ l /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 >-rw-r--r-- 1 root root 391928 Jun 15 13:36 >/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 It is odd in that it deviates from standard practices. Only 4% of .so libraries in my /usr/lib64 have 644, the other 96 have 755. Pristine libtool does not pass -m 644, and default (GNU) install defaults to mode 755 when not specifying anything else. glibc-ldd even thinks it wants to warn about it. 20:24 wrgstfl:~ > ldd /usr/lib64/libssl.so.27 ldd: warning: you do not have execution permission for `/usr/lib64/libssl.so.27' linux-vdso.so.1 (0x7fff4c3fe000) libc.so.6 => /lib64/libc.so.6 (0x7ff5bca38000) /lib64/ld-linux-x86-64.so.2 (0x7ff5bd069000) (Whatever the reason +x is set on libs, doing so is standard practice.)
Re: LibreSSL 2.0.1 released - installation extra_mode
On Sunday 2014-07-13 13:07, Bob Beck wrote: >We have released an update, LibreSSL 2.0.1 >As noted before, we welcome feedback from the broader community. Something that I have noticed is that the shared libraries generated by the portable libressl tarball are installed to their final location (in DESTDIR) with odd mode 644. Looking a bit into it, this originates in libressl-2.0.1/ltmain.sh: $ grep extra_mode -r . ./ltmain.sh:*[\\\ /]cp\ *) extra_mode=;; ./ltmain.sh:*) extra_mode='-m 0644';; [...] However, the unmodified libtool sources (git://git.sv.gnu.org/libtool) do not contain any mention of "extra_mode", so this seems like a OpenBSD-specific addition that should not be applied to the portable package. (IOW, run autoreconf using unmodified libtool.)
Re: LibreSSL 2.0.1 released
On Sunday 2014-07-13 17:36, Brent Cook wrote: >>> >>> This release includes a number of portability fixes based on the >>> initial feedback we have received from the community. >> >> I was looking at Solaris documentation and found that -lrt may be >> needed for some versions as well. A test has not been conducted. > >Thanks Jan, we fixed this in a more generic way: > >https://github.com/libressl-portable/portable/commit/7a9aa4dd7eaa91a532af39ff20fac09e49f2 Ah yes, interesting. JFYI, mingw-w64 has clock_gettime in -lpthread instead, so that needs to be tested as well.
Re: LibreSSL 2.0.1 released
On Sunday 2014-07-13 13:07, Bob Beck wrote: > >This release includes a number of portability fixes based on the >initial feedback >we have received from the community. I was looking at Solaris documentation and found that -lrt may be needed for some versions as well. A test has not been conducted. ---8<--- According to Solaris documentation[1,2], clock_gettime is to be found in librt until including Solaris 10. [1] http://docs.oracle.com/cd/E23823_01/html/816-5171/clock-getres-3rt.html [2] http://docs.oracle.com/cd/E23824_01/html/821-1465/clock-gettime-3c.html --- configure.ac |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: libressl-2.0.1/configure.ac === --- libressl-2.0.1.orig/configure.ac +++ libressl-2.0.1/configure.ac @@ -21,7 +21,7 @@ case $target_os in *solaris*) TARGET_OS=solaris; CFLAGS="$CFLAGS -D__EXTENSIONS__ -D_XOPEN_SOURCE=600 -DBSD_COMP" - AC_SUBST([PLATFORM_LDADD], ['-lnsl -lsocket']) + AC_SUBST([PLATFORM_LDADD], ['-lnsl -lsocket -lrt']) ;; *openbsd*) AC_DEFINE([HAVE_ATTRIBUTE__BOUNDED__], [1], [OpenBSD gcc has bounded])
Re: First release of LibreSSL portable is available.
> CCLD openssl >../crypto/.libs/libcrypto.so: undefined reference to `clock_gettime' >collect2: ld returned 1 exit status >make[1]: *** [openssl] Error 1 > >Setting LDFLAGS to -lrt fixes the issue. Rather than LDFLAGS, it should be in LDADD/LIBADD. --8<-- Subject: build: resolve link-time failure libtool: link: gcc -O2 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -Werror -std=c99 -g -Wno-pointer-sign -D_BSD_SOURCE -D_POSIX_SOURCE -D_GNU_SOURCE -o .libs/openssl [ *.o ... ] ../crypto/.libs/libcrypto.so ../ssl/.libs/libssl.so -Wl,-rpath -Wl,/usr/lib64 ../crypto/.libs/libcrypto.so: undefined reference to `clock_gettime' collect2: error: ld returned 1 exit status --- crypto/Makefile.am |3 +++ 1 file changed, 3 insertions(+) Index: libressl-2.0.0/crypto/Makefile.am === --- libressl-2.0.0.orig/crypto/Makefile.am +++ libressl-2.0.0/crypto/Makefile.am @@ -19,6 +19,7 @@ libcompatnoopt_la_SOURCES = compat/expli # other compatibility functions libcompat_la_CFLAGS = $(CFLAGS) $(USER_CFLAGS) libcompat_la_SOURCES = +libcompat_la_LIBADD = if NO_STRLCAT libcompat_la_SOURCES += compat/strlcat.c @@ -46,12 +47,14 @@ libcompat_la_SOURCES += compat/arc4rando if NO_GETENTROPY if TARGET_LINUX libcompat_la_SOURCES += compat/getentropy_linux.c +libcompat_la_LIBADD += -lrt endif if TARGET_DARWIN libcompat_la_SOURCES += compat/getentropy_osx.c endif if TARGET_SOLARIS libcompat_la_SOURCES += compat/getentropy_solaris.c +libcompat_la_LIBADD += -lrt endif endif
Re: First release of LibreSSL portable is available.
>The first release of LibreSSL portable has been released. LibreSSL >can be found in the LibreSSL directory of your favorite OpenBSD >mirror. > >http://ftp.openbsd.org/pub/OpenBSD/LibreSSL has it, and other >mirrors will soon. > >libressl-2.0.0.tar.gz has been tested to build on various versions >of Linux, Solaris, Mac OSX, and FreeBSD. Greetings. The check_PROGRAMS do not build error-free currently. I have applied the below changes to my copy of the libressl source, maybe you want to do something similar. ---8<--- (quilt patch) Date: 2014-07-12 11:21:03.199722087 +0200 Subject: build resolve compile abort due to type punning and -Werror gcc-4.8 said, upon `make check`: biotest.c: In function 'do_bio_get_host_ip_tests': biotest.c:101:3: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] if (ret && ntohl(*((uint32_t *)ip)) != bgit->ip) { ^ biotest.c:104:8: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] ntohl(*((uint32_t *)ip)), bgit->ip); ^ As "ip" may be not be properly aligned for uint32_t, copy it to a uint32_t before ntohling. --- tests/biotest.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) Index: libressl-2.0.0/tests/biotest.c === --- libressl-2.0.0.orig/tests/biotest.c +++ libressl-2.0.0/tests/biotest.c @@ -77,15 +77,25 @@ struct bio_get_port_test bio_get_port_te #define N_BIO_GET_PORT_TESTS \ (sizeof(bio_get_port_tests) / sizeof(*bio_get_port_tests)) +#ifndef BUILD_BUG_ON_EXPR +# define BUILD_BUG_ON_EXPR(condition) (sizeof(char[1 - 2 * !!(condition)]) - 1) +#endif +#ifndef BUILD_BUG_ON +# define BUILD_BUG_ON(condition) ((void)BUILD_BUG_ON_EXPR(condition)) +#endif + static int do_bio_get_host_ip_tests(void) { struct bio_get_host_ip_test *bgit; unsigned char ip[4]; + uint32_t ipout; int failed = 0; size_t i; int ret; + BUILD_BUG_ON(sizeof(ip) != sizeof(ipout)); + for (i = 0; i < N_BIO_GET_IP_TESTS; i++) { bgit = &bio_get_host_ip_tests[i]; memset(ip, 0, sizeof(*ip)); @@ -98,10 +108,12 @@ do_bio_get_host_ip_tests(void) failed = 1; continue; } - if (ret && ntohl(*((uint32_t *)ip)) != bgit->ip) { + if (ret && + memcpy(&ipout, ip, sizeof(ip)) != NULL && + ntohl(ipout) != bgit->ip) { fprintf(stderr, "FAIL: test %zi (\"%s\") returned ip " "%x != %x\n", i, bgit->input, - ntohl(*((uint32_t *)ip)), bgit->ip); + ntohl(ipout), bgit->ip); failed = 1; } }