openssl and bash libcrypto

[Kimmo Paasiala]

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.

-Kimmo