#101 Mac OS X 10.13 OpenSSL support

[u235]

Adium Debug and Apple Report Logs:
https://gist.github.com/qayshp/9a3e051474a325d90ac8186284d3aae8

[Stefan Becker]

Looks like High SIerra is incorrectly loading BoringSSL dynamic libraries instead of the requested OpenSSL libraries. Those libraries have the same APIs (BoringSSL is a fork of OpenSSL) but are binary incompatible to each other, which leads to the crash when SIPE calls crypto functions from the backend.

A possible solution might be this change, but it would need to be tested if after this change the binary still works on older Mac OS X.

Therefore this is not a bug, but must be handled as feature request.

[Stefan Becker]

Ticket moved from /p/sipe/bugs/332/

Can't be converted:

• _milestone: 1.22.x

[Stefan Becker]

Can somebody who has High Sierra (10.13) install run the following 2 commands in Terminal and post the output here? In my examples I give output from Sierra (10.12):

$ ls -lhta /usr/lib/libcrypto.*
-rwxr-xr-x  1 root  wheel   2.6M Apr 29 04:59 /usr/lib/libcrypto.0.9.8.dylib
lrwxr-xr-x  1 root  wheel    21B Mar 23  2017 /usr/lib/libcrypto.dylib -> libcrypto.0.9.8.dylib
-rwxr-xr-x  1 root  wheel   1.9M Mar 23  2017 /usr/lib/libcrypto.0.9.7.dylib
-rw-r--r--  1 root  wheel   4.0M Mar 23  2017 /usr/lib/libcrypto.35.dylib
-rw-r--r--  1 root  wheel   4.0M Mar 23  2017 /usr/lib/libcrypto.38.dylib

$ strings /usr/lib/libcrypto.35.dylib | fgrep -i -e "OpenSSL " -e "LibreSSL " -e "BoringSSL "
%s(%d): OpenSSL internal error, assertion failed: %s
LibreSSL 2.2.7
OpenSSL CMAC method
OpenSSL default
OpenSSL PKCS#3 DH method
OpenSSL DH Method
OpenSSL DSA method
OpenSSL EC algorithm
OpenSSL ECDH method
OpenSSL ECDSA method
OpenSSL HMAC method
OpenSSL RSA method
OpenSSL default user interface

If I interpret the crash log correctly then on 10.13

• /usr/lib/libcrypto.dylib has been changed to point to librypto.35.dylib
• /usr/lib/libcrypto.35.dylib source code has been changed from LibreSSL to BoringSSL

[Brandon Applegate]

Fully updated 10.13.

onosendai:~   vom$ ls -lhta /usr/lib/libcrypto.*
lrwxr-xr-x  1 root  wheel    18B Oct  8 06:46 /usr/lib/libcrypto.dylib -> libcrypto.35.dylib
-rw-r--r--  1 root  wheel   4.1M Sep 21 00:35 /usr/lib/libcrypto.41.dylib
-rwxr-xr-x  1 root  wheel   1.9M Sep 21 00:35 /usr/lib/libcrypto.0.9.7.dylib
-rwxr-xr-x  1 root  wheel   2.5M Sep 21 00:35 /usr/lib/libcrypto.0.9.8.dylib
-rw-r--r--  1 root  wheel   4.0M Sep 21 00:35 /usr/lib/libcrypto.35.dylib

onosendai:~   vom$ strings /usr/lib/libcrypto.35.dylib | fgrep -i -e "OpenSSL " -e "LibreSSL " -e "BoringSSL "
%s(%d): OpenSSL internal error, assertion failed: %s
LibreSSL 2.2.7
OpenSSL CMAC method
OpenSSL default
OpenSSL PKCS#3 DH method
OpenSSL DH Method
OpenSSL DSA method
OpenSSL EC algorithm
OpenSSL ECDH method
OpenSSL ECDSA method
OpenSSL HMAC method
OpenSSL RSA method
OpenSSL default user interface

[Stefan Becker]

I think I found a quick fix, but that will always require building against an older SDK than 10.13.

Can you please try this release package on 10.13? It should now load the OpenSSL 0.9.8 libcrypto dynamic library instead of the default libcrypto dynamic library.

[Andre]

Stefan, the updated version works flawlessly.

[Stefan Becker]

Thanks for the feedback, Andre.

Final solution pushed as git commit 0a8e5a64.

It would still be nice to get the output of the two commands from High Sierra.

Root cause was a mistake I maded implementing the OpenSSL support for the Adium plugin: I should have added -lcrypto to the linker command line. Unfortunately the plugin code needs to be linked with -undefined dynamic_lookup which hides the problem, i.e. there are no linker errors due to missing symbols. I had been wondering why this works and now I know why.

When Adium is running, some other dependency (maybe CDSA?) must already load libcrypto.dylib into the virtual address space, i.e. when Adium loads the SIPE plugin the OpenSSL references get resolved without problems by the dynamic loader. Until OS X 10.13 this worked, because the dependency triggered the load of libcrypto.0.9.8.dylib. But in OS X 10.13 a newer libcrypto.dylib gets loaded, which has the same symbol names, but is binary incompatible to 0.9.8.

Now the linker command line includes a reference to librypto.0.9.8.dylib and thus the SIPE binary has an explicit dependency on it. This makes sure the dynamic linker loads the correct library and resolves the OpenSSL references with that version. This should work until Apple decides to drop backward compatibility, i.e. by removing libcrypto.0.9.8.dylib from the system.

Closing as IMPLEMENTED.