openssl and bash libcrypto

[Baptiste Daroussin]

On Thu, Apr 09, 2015 at 05:52:48PM +0300, Kimmo Paasiala wrote:
> On Thu, Apr 9, 2015 at 3:43 PM, Dewayne Geraghty
> <dewayne.geraghty at heuristicsystems.com.au> wrote:
> >
> > On 9/04/2015 10:02 PM, Kimmo Paasiala wrote:
> >> On Thu, Apr 9, 2015 at 1:42 PM, Aristedes Maniatis <ari at ish.com.au> wrote:
> >>> Starting in the last week or so, several different applications are exhibiting the same symptoms of broken libcrypto libraries.
> >>>
> >>> (gdb) core bash.core
> >>> Core was generated by `bash'.
> >>> Program terminated with signal 11, Segmentation fault.
> >>>
> >>> (gdb) bt
> >>> #0  0x00000008029cafe5 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.8
> >>> #1  0x00000008033cf0b9 in OPENSSL_ia32cap_loc () from /lib/libcrypto.so.7
> >>> #2  0x00000008032d584e in _init () from /lib/libcrypto.so.7
> >>> #3  0x00007fffffffd7c0 in ?? ()
> >>> #4  0x00000008006d66bf in r_debug_state () from /libexec/ld-elf.so.1
> >>> #5  0x00000008006dad87 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1
> >>> #6  0x00000008006d7ad3 in dlopen () from /libexec/ld-elf.so.1
> >>> #7  0x0000000800e5c436 in _nsdbtaddsrc () from /lib/libc.so.7
> >>> #8  0x0000000800e563c9 in _nsyyparse () from /lib/libc.so.7
> >>> #9  0x0000000800e5cab1 in nsdispatch () from /lib/libc.so.7
> >>> #10 0x0000000800e49ebe in getpwuid () from /lib/libc.so.7
> >>> #11 0x0000000800e49cbf in getpwnam () from /lib/libc.so.7
> >>>
> >>>
> >>> Although that symptom is in bash, I've got the exact same symptoms in asterisk. The builds are done in poudriere with the make flags:
> >>>
> >>> WITH_OPENSSL_PORT=yes
> >>>
> >>>
> >>> I've tried updating to the latest 10.1-RELEASE-p6, although it is possible that that is exactly what caused the problem in the first place when the poudriere jail was updated to that release.
> >>>
> >>> The function calls mention ia32 but this box is purely 64bit.
> >>>
> >>>
> >>> I've seen recent discussions about the problems that confusion between core openssl and ports openssl can cause. But I can't for the life of me figure how to avoid this problem.
> >>>
> >>> * Should bash be built with "Build static executables and/or libraries"?
> >>> * Should I stop trying to use openssl from ports until this is fixed?
> >>> * Why is /lib/libcrypto.so.7 calling /usr/local/lib/libcrypto.so.8 ?
> >>>
> >>> I've tried so many different combinations of settings, I don't know what to try next.
> >>>
> >>> Thanks
> >>> Ari
> >>>
> >>>
> >>> --
> >>> -------------------------->
> >>> Aristedes Maniatis
> >>> ish
> >>> http://www.ish.com.au
> >>> Level 1, 30 Wilson Street Newtown 2042 Australia
> >>> phone +61 2 9550 5001   fax +61 2 9550 4001
> >>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
> >>>
> >> You could build world with WITHOUT_OPENSSL but that would also disable
> >> some other needed pieces such as OpenSSH and you'd have to install
> >> them from ports.
> >>
> >> WITHOUT_OPENSSL
> >>              Set to not build OpenSSL.  When set, it also enforces the follow‐
> >>              ing options:
> >>
> >>              WITHOUT_KERBEROS
> >>              WITHOUT_KERBEROS_SUPPORT
> >>              WITHOUT_OPENSSH
> >>
> >>              When set, the following options are also in effect:
> >>
> >>              WITHOUT_GSSAPI (unless WITH_GSSAPI is set explicitly)
> >> _______________________________________________
> >> freebsd-ports at freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> >> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
> >>
> >>
> >>
> > Take care, as: geli, pkg and tar will fail to build, the latter due to
> > libarchive, and libfetch as also being affected.  I went down this path
> > a few years ago, but stopped when the ability to install
> > security/openssl into /usr was instituted.  (geli only needs openssl
> > headers).  As an FYI, I build all ports using security/openssl though
> > heimdal and a few others are a challenge because they try/tried to use
> > base openssl libcom_err.so.
> > I'd suggest making a backup of the openssl libs (crypto, ssl),
> > pkg-static and verify /rescue/tar is available, so that you have a
> > recovery route.
> >
> 
> Aah yes, it's no-go then if it breaks pkg(8)...
> 
> One solution that comes to my mind would be to use two-level
> namespaces for symbol resolution. The first part would be the module
> name and the second part the symbol name. Any shared libraries
> produced by ports(7) would be required to prepend 'ports-' to the
> module name. This would eliminate any possibility of dynamic symbol
> clashes between ports and the base system.
> 
There is an ongoing work to enforce libcrypto/libssl from ports for anything but
pkg(8) we hope to be able to make that happen soon, but of cour $soon is
undefined :)

Best regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20150409/63e83df6/attachment.sig>