On 2024/05/21 18:04:18 Christopher Schultz wrote: > Michael, > > On 5/21/24 03:32, Michael Osipov wrote: > > On 2024/05/20 13:30:43 Christopher Schultz wrote: > >> Michael, > >> > >> On 5/20/24 06:52, Michael Osipov wrote: > >>> On 2024/05/17 15:11:58 Christopher Schultz wrote: > >>>> Michael, > >>>> > >>>> On 5/17/24 03:42, Michael Osipov wrote: > >>>>> On 2024/05/16 21:37:34 Christopher Schultz wrote: > >>>>>> Michael, > >>>>>> > >>>>>> On 5/16/24 12:00, Michael Osipov wrote: > >>>>>>> On 2024/05/16 15:55:04 Andy Arismendi wrote: > >>>>>>>> Ok great! Thank you for taking the time and making the effort to > >>>>>>>> look into this Michael, much appreciated! > >>>>>>> > >>>>>>> Here is a dynamically linked, patched version until there is an > >>>>>>> official release: > >>>>>>> http://home.apache.org/~michaelo/issues/tomcat/openssl-crash/ > >>>>>>> > >>>>>>> Please give it a try. > >>>>>> > >>>>>> Since you have produced a debug build of tcnative (and other > >>>>>> components?) could you post the debug trace of the native stack? > >>>>> > >>>>> Unfortunately I can't. While I have the files with debug symbols I am > >>>>> limited by https://github.com/mturk/cmsc?tab=readme-ov-file#warning. I > >>>>> don't have a full blown Visual Studio installed. > >>>> > >>>> Okay. If you did build with VS, can you get a debug build with a > >>>> backtrace? > >>> > >>> Unfortunately not. Currently, I don't have the capacity to do so. > >>> > >>>> I guess you already tracked the crash to openssl_fopen. When I did a > >>>> decompile of the official binary, I can see the code but it's very > >>>> difficult to read: > >>>> > >>>> void FUN_1800cccd0(char *param_1,char *param_2) > >>>> > >>>> { > >>>> .... > >>>> } > >>>> > >>>> Thanks for helping to at least link it to this openssl source: > >>>> > >>>> https://github.com/openssl/openssl/blob/45f5d51b72a262bf85c4461fbded91485ce6b9da/crypto/o_fopen.c#L38 > >>>> > >>>> Since libtcnative.dll is statically-linked, it doesn't even need a > >>>> symbol table for internal calls so the openssl_fopen token is completely > >>>> lost. Also, libtcnative contains all of TCN, APR, and OpenSSL. TCN > >>>> doesn't make direct Win32 calls so that leaves ... all of APR and > >>>> OpenSSL to search for this pattern of calls. > >>>> > >>>> Since you know where the fault is occurring, do you know the native > >>>> call-trace being performed? I'd love to know which component along the > >>>> way is not properly checking for NULL. > >>> > >>> Yes, sure: > >>> * > >>> https://github.com/apache/tomcat-native/blob/6a6a6b2395036c6a6cabb2b8af22aa329e438436/native/src/sslcontext.c#L711 > >> > >> So, 'file' is null on this line? If so, I guess the bug is in tcnative. > > > > Yes, it is NULL. I don't think that the bug in necessarily in tcnative > > because othe functions in OpenSSL do support NULL and fail appropriately. I > > consider this either bad documenation or missing input validation. > > > >>> * > >>> https://github.com/openssl/openssl/blob/45f5d51b72a262bf85c4461fbded91485ce6b9da/ssl/ssl_cert.c#L834 > >>> * > >>> https://github.com/openssl/openssl/blob/45f5d51b72a262bf85c4461fbded91485ce6b9da/crypto/o_fopen.c#L42 > >> > >> Where does the call go from BIO_read_filename to openssl_fopen? > > > > Here: > > https://github.com/openssl/openssl/blob/45f5d51b72a262bf85c4461fbded91485ce6b9da/crypto/bio/bss_file.c#L267-L295 > > That's in file_ctrl(). What's the full call trace from tcnative's > setCACertificate through to openssl_fopen?
BIO_read_filename() is a macro, if you trace down the resolution manually you will end up in the resources I have provided you. Took me some time. M --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
