search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.16k stars 4.71k forks source link

Dotnet segfault in libSystem.Security.Cryptography.Native.OpenSsl.so #99368

Open shahankur11 opened 7 months ago

shahankur11 commented 7 months ago

Description

I have a native app which is hosting a managed library using the coreclrhost apis. The app crashes with the following exception stack as soon as the managed APIs invoked.

(gdb) bt

0 0x0000000016a73684 in EC_GROUP_order_bits ()

1 0x00007fbe2d127bbd in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3

2 0x00007fbe2d12df1b in ENGINE_init () from /lib/x86_64-linux-gnu/libcrypto.so.3

3 0x00007fbe2d164431 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3

4 0x00007fffeb2c73d3 in SSL_CTX_new_ex () from /lib/x86_64-linux-gnu/libssl.so.3

5 0x00007fffeb34b429 in CryptoNative_EnsureLibSslInitialized () from /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.2/libSystem.Security.Cryptography.Native.OpenSsl.so

6 0x00007ffed4c988df in ?? ()

7 0x00000000011c72b6 in ?? ()

8 0x00007fff52cf93c8 in ?? () from /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.2/libcoreclr.so

9 0x00007fbe2fdf6218 in ?? ()

10 0x0000000000000000 in ?? ()

The Testbinary is also loading openssl as a static lib. So the problem seems to point to a conflict between the dynamically loaded openssl lib by coreclr and statically loaded lib (by the testprogram). (gdb) info symbol EC_GROUP_order_bits EC_GROUP_order_bits in section .text of /mnt/c/temp/dumpstore/testbinary

Any suggestions on how do folks typically go about resolving such conflicts? I am using dotnet version 8.0.2. I can share the binary/dump privately if needed.

Reproduction Steps

link to openssl statically, load coreclr, and invoke crypto apis.

Expected behavior

no crash

Actual behavior

(gdb) bt

0 0x0000000016a73684 in EC_GROUP_order_bits ()

1 0x00007fbe2d127bbd in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3

2 0x00007fbe2d12df1b in ENGINE_init () from /lib/x86_64-linux-gnu/libcrypto.so.3

3 0x00007fbe2d164431 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3

4 0x00007fffeb2c73d3 in SSL_CTX_new_ex () from /lib/x86_64-linux-gnu/libssl.so.3

5 0x00007fffeb34b429 in CryptoNative_EnsureLibSslInitialized () from /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.2/libSystem.Security.Cryptography.Native.OpenSsl.so

6 0x00007ffed4c988df in ?? ()

7 0x00000000011c72b6 in ?? ()

8 0x00007fff52cf93c8 in ?? () from /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.2/libcoreclr.so

9 0x00007fbe2fdf6218 in ?? ()

10 0x0000000000000000 in ?? ()

can share dumps privately.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

ghost commented 7 months ago

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones See info in area-owners.md if you want to be subscribed.

Issue Details
### Description I have a native app which is hosting a managed library using the coreclrhost apis. The app crashes with the following exception stack as soon as the managed APIs invoked with the following stack. (gdb) bt #0 0x0000000016a73684 in EC_GROUP_order_bits () #1 0x00007fbe2d127bbd in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3 #2 0x00007fbe2d12df1b in ENGINE_init () from /lib/x86_64-linux-gnu/libcrypto.so.3 #3 0x00007fbe2d164431 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3 #4 0x00007fffeb2c73d3 in SSL_CTX_new_ex () from /lib/x86_64-linux-gnu/libssl.so.3 #5 0x00007fffeb34b429 in CryptoNative_EnsureLibSslInitialized () from /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.2/libSystem.Security.Cryptography.Native.OpenSsl.so #6 0x00007ffed4c988df in ?? () #7 0x00000000011c72b6 in ?? () #8 0x00007fff52cf93c8 in ?? () from /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.2/libcoreclr.so #9 0x00007fbe2fdf6218 in ?? () #10 0x0000000000000000 in ?? () The Testbinary is also loading openssl as a static lib. So the problem seems to point to a conflict between the dynamically loaded openssl lib by coreclr and statically loaded lib (by the testprogram). (gdb) info symbol EC_GROUP_order_bits EC_GROUP_order_bits in section .text of /mnt/c/temp/dumpstore/testbinary Any suggestions on how do folks typically go about resolving such conflicts? I am using dotnet version 8.0.2. I can share the binary/dump privately if needed. ### Reproduction Steps link to openssl statically, load coreclr, and invoke crypto apis. ### Expected behavior no crash ### Actual behavior (gdb) bt #0 0x0000000016a73684 in EC_GROUP_order_bits () #1 0x00007fbe2d127bbd in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3 #2 0x00007fbe2d12df1b in ENGINE_init () from /lib/x86_64-linux-gnu/libcrypto.so.3 #3 0x00007fbe2d164431 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3 #4 0x00007fffeb2c73d3 in SSL_CTX_new_ex () from /lib/x86_64-linux-gnu/libssl.so.3 #5 0x00007fffeb34b429 in CryptoNative_EnsureLibSslInitialized () from /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.2/libSystem.Security.Cryptography.Native.OpenSsl.so #6 0x00007ffed4c988df in ?? () #7 0x00000000011c72b6 in ?? () #8 0x00007fff52cf93c8 in ?? () from /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.2/libcoreclr.so #9 0x00007fbe2fdf6218 in ?? () #10 0x0000000000000000 in ?? () can share dumps privately. ### Regression? _No response_ ### Known Workarounds _No response_ ### Configuration _No response_ ### Other information _No response_
Author: shahankur11
Assignees: -
Labels: `area-System.Security`
Milestone: -
bartonjs commented 7 months ago

Does the problem go away if you make your application use a dynamic link to OpenSSL?

You're well off in the weeds here. While some people have done static linking of OpenSSL into libSystem.Security.Cryptography.Native.so, I've never heard of your particular configuration; and it's not something that we would have time to investigate.

shahankur11 commented 7 months ago

The application is a legacy app with lots of other dependencies (also loading openssl statically). So rewiring everything to use dynamic libs is a tall ask.

While some people have done static linking of OpenSSL into libSystem.Security.Cryptography.Native.so

Any pointers on how to make this happen?

shahankur11 commented 7 months ago

also, i am not sure why the "os-unsupported" tag was added. its running on ubuntu 22.04. Is that not supported?

bartonjs commented 7 months ago

also, i am not sure why the "os-unsupported" tag was added. its running on ubuntu 22.04. Is that not supported?

The OS is, but the way you're building your application is not. There wasn't a better label for "this is outside of what we support".

bartonjs commented 7 months ago

https://github.com/dotnet/runtime/issues/80654 talks about building fully static applications. It looks like (from https://github.com/dotnet/runtime/blob/main/src/native/libs/System.Security.Cryptography.Native/CMakeLists.txt) that libSystem.Security.Cryptography.Native.a (statically linked against libcrypto/libssl) is always built; but I don't know where or how you get at it unless you build dotnet/runtime yourself.

As noted in the linked issue, or perhaps in the PR that turned on the feature for linking OpenSSL statically: Statically linking OpenSSL goes against security best practices. It might be reasonable for applications that are continually rebuilt and redeployed in Docker-style configurations; but it should basically never be done for an application that is run on a long-lived computer.