Open ilammy opened 4 years ago
This issue is caused by duplicate OpenSSL symbols.
Due to the way ELF linkage and loading works on Linux, Themis may be using OpenSSL functions different from the ones it was compiled. ABI mismatches are sometimes unnoticeable, sometimes lead to crashes, and sometimes lead to unexpected behavior.
⚠️ Warning: Using JsThemis with prebuilt Themis Core packages may be not safe. If you can, please build Themis Core from source for now.
Normally, JsThemis addon uses Themis Core libraries installed from binary packages hosted by Cossack Labs. We build there packages for various distros, using the OpenSSL package provided by the distro. That way JsThemis gets all security updates in OpenSSL essentially for free, from a package maintained by distro maintainers.
This is how linkage and installation should look in the ideal case:
Node.js loads JsThemis, which uses Themis which uses Soter which uses OpenSSL installed into the system.
Node.js binary includes its own copy of OpenSSL inside it. It has been like this historically, and it is important for some native add-ons which expect OpenSSL to be available with just Node.js.
However, due to way symbol lookup works on Linux, this is what happens:
Soter uses OpenSSL functions from the Node.js binary, not the ones from system’s OpenSSL. It is still loaded, but mostly ignored after that.
Sometimes it is fine since OpenSSL does a good job at keeping ABI compatibility. However, if Node.js was built with a different version of OpenSSL than the one installed in the system, then ABI mismatch may happen. Data structures will have different layout, function implementations may be different, etc. This causes undefined behavior, most likely leading to a crash.
Though, if OpenSSL versions in system and Node.js match then JsThemis will kinda work fine.
Unfortunately, we can’t change the way linkage works on Linux. And we can’t remove OpenSSL from Node.js. Therefore, we are planning to switch to the following scheme in a future release:
By using embedded BoringSSL, Soter will use the library it was built with, avoiding the possibility of symbol clash and ABI mismatch.
This approach is tracked in issue #619.
Another way this issue can be solved is to link Soter against Node.js OpenSSL:
This will avoid duplicating cryptographic code in memory (due to OpenSSL and BoringSSL being loaded), but it’s not really practical for us. We’d have to build Themis for each individual Node.js version. Then we’d need to teach the users to install a version of Themis that matches their Node.js installation (or have the users build Themis from source). This is not very convenient, both for us and the users.
Furthermore, using BoringSSL allows us to issue security updates to Themis independently of Node.js security updates.
Describe the bug Any call to JsThemis method can cause the
node
binary to crash with “Segmentation fault” error.Only some systems with older Node.js binaries are affected. See below for details.
To Reproduce Steps to reproduce the behavior:
Developers can reproduce the issue by running JsThemis unit tests:
Expected behavior JsThemis should not crash, regardless of Node.js version and build.
Environment:
Node.js versions known to be affected:
Additional context There is a known workaround. Do not install install Themis Core from Cossack Labs package repositories. Instead, compile and install Themis Core from source, using BoringSSL: