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;
}
}
