microsoft / vcpkg

C++ Library Manager for Windows, Linux, and MacOS
MIT License
22.95k stars 6.34k forks source link

xmlSec: xmlSecDSigCtxDebugDump Access Violation #34932

Open hafedh-trimeche opened 11 months ago

hafedh-trimeche commented 11 months ago

Describe the bug xmlSecDSigCtxDebugDump Acces Violation.

Environment

To Reproduce Steps to reproduce the behavior:

  1. xmlSecDSigCtxSign(dsigCtx,SignatureNode);
  2. xmlSecDSigCtxDebugDump

Expected behavior xmlSecDSigCtxDebugDump reports a signature log.

JonLiu1993 commented 11 months ago

@hafedh-trimeche, Thanks for posting this issue, please provide your detailed error reproduction steps and error logs.

hafedh-trimeche commented 11 months ago

Hi,

Please find this log: xmlsec 1.3.1#1

:00007FFBB708090D ; C:\Windows\System32\ucrtbased.dll
:00007FFBB7036966 ; C:\Windows\System32\ucrtbased.dll
:00007FFBB704E3CA ; C:\Windows\System32\ucrtbased.dll
:00007FFBB704E4C8 ; C:\Windows\System32\ucrtbased.dll
:00007FFBB704F17A ; C:\Windows\System32\ucrtbased.dll
:00007FFBB707912C ; C:\Windows\System32\ucrtbased.dll
:00007FFBD9377CC0 ; D:\xmlsec\libxmlsec1.dll
:00007FFBD9377D30 ; D:\xmlsec\libxmlsec1.dll
:00007FFBD93C525E ; D:\xmlsec\libxmlsec1.dll
uXMLSec.DumpDSigDebug($1E6BCAD38D0)

and this one:

[00007FFBB7036966] Unknown function at ferror + $476
[00007FFBB704E3CA] Unknown function at __p__commode + $DDA
[00007FFBB704E4C8] Unknown function at __p__commode + $ED8
[00007FFBB704F17A] Unknown function at __p__commode + $1B8A
[00007FFBB707912C] __stdio_common_vfprintf + $5C
[00007FFBDB107CC0] Unknown function at xmlSecSimpleKeysStoreAdoptKey + $25EB5
[00007FFBDB107D30] Unknown function at xmlSecSimpleKeysStoreAdoptKey + $25F25
[00007FFBDB15525E] Unknown function at xmlSecSimpleKeysStoreAdoptKey + $73453
[0000000001780B26] uXMLSec.DumpDSigDebug (Line 175, "uXMLSec.pas" + 2) + $14

uXMLSec.DumpDSigDebug is calling: xmlSecDSigCtxDebugDump(dsigCtx,xmlSecDSigOutput) Please which sizes 32/64 of time_t & xmlSecSize for the version 1.3.1#1? According to the documentation, xmlSecSize should have a 64 length (size_t).

core xmlsec and all xmlsec-crypto libraries:

    (ABI breaking change) Added support for the [KeyInfoReference Element](https://www.w3.org/TR/xmldsig-core1/#sec-KeyInfoReference).
    (ABI breaking change) Switched xmlSecSize to use size_t by default. Use "--enable-size-t=no" configure option ("size_t=no" on Windows) to restore the old behaviour (note that support for xmlSecSize being different from size_t will be removed in the future).
    (API breaking change) Changed the key search to strict mode: only keys referenced by KeyInfo are used. To restore the old "lax" mode, set XMLSEC_KEYINFO_FLAGS_LAX_KEY_SEARCH flag on xmlSecKeyInfoCtx or use '--lax-key-search' option for XMLSec command line utility.
    (API breaking change) The KeyName element content is now trimmed before key search is performed.
    (API breaking change) Disabled FTP support by default. Use "--enable-ftp" configure option to restore it. Also added "--enable-http" and "--enable-files" configure options to control support for loading files over HTTP or locally.
    (API/ABI breaking change) Disabled MD5 digest method by default. Use "--enable-md5" configure options ("legacy-crypto" option on Windows) to re-enable MD5.
    (ABI breaking change) Added "failureReason" file to xmlSecDSigCtx and xmlEncCtx to provide more granular operation failure reason.
    (ABI breaking change) Removed deprecated functions.
    Added support for loading keys through [ossl-store](https://www.openssl.org/docs/man3.0/man7/ossl_store.html) interface (e.g. for using keys from an HSM). Also see '--privkey-openssl-store' and '--pubkey-openssl-store ' command line options for XMLSec utility.
    Added ability to control transforms binary chunk size to improve performance (see '--transform-binary-chunk-size' command line option for XMLSec utility).
    Fixed all potentially unsafe integer conversions and all the other warnings.
    Added [XML Signature 1.1 interop (2012)](https://www.w3.org/TR/2012/NOTE-xmldsig-core1-interop-20121113/) and [XML Encryption 1.1 interop (2012)](https://www.w3.org/TR/2012/NOTE-xmlenc-core1-interop-20121113/) tests.

Best regards.

JonLiu1993 commented 11 months ago

@hafedh-trimeche, My computer is 64 bit and I can build xmlSecport successfully:

printf("sizeof time_t is: %d\n", sizeof(time_t));

output:

sizeof time_t is: 8
JonLiu1993 commented 10 months ago

@hafedh-trimeche, Does this problem still exist?

hafedh-trimeche commented 10 months ago

Yes it does: xmlsec 1.3.1#2

JonLiu1993 commented 10 months ago

xmlSec has the latest version 1.3.2, do I need to update it?

hafedh-trimeche commented 10 months ago

Sorry I can't! I'm using VCPKG which automatically generates library. Waiting for the next version. You can check https://github.com/lsh123/xmlsec

JonLiu1993 commented 10 months ago

I will submit a PR as soon as possible to upgrade xmlSec in vcpkg to 1.3.2. You can test it on your local machine by then.

lsh123 commented 9 months ago

I don't believe changes in 1.3.2 would resolve this problem. Overall, this looks like one of the two possible issues for me:

JonLiu1993 commented 3 months ago

@hafedh-trimeche, The latest xmlsec 1.3.4 can solved your issue?

hafedh-trimeche commented 3 months ago

Hello, Even VCPKG updated, xmlsec still at version 1.3.3: image

With the same result!

dg0yt commented 3 months ago

Did you ever check if you call the function with the right argument types, build with the right link lib, run with the right runtime lib? IIUC the call is coming from pascal (Line 175, "uXMLSec.pas" + 2). Not sure if there aren't more traps at the language boundary.

hafedh-trimeche commented 3 months ago

xmlSecDSigCtxDebugDump has only two (2) parameters: dsigCtx & output which are pointers. output is open using fopen('xmlSec.log','w') and shouldn't cause problem. It seams that the library doesn't check some null values before dumping related content. The calling convention doesn't matter because the library is a 64 bit one. Best regards.

hafedh-trimeche commented 3 months ago

I used fopen and fclose function statically linked to open and close Log file: https://github.com/tinyBigGAMES/CPas/blob/main/lib/CPas.CRuntime.pas

This exception is raised:

OpenSSL: FATAL
---------------------------
OPENSSL_Uplink(00007FFD4F3DCA38,08): no OPENSSL_Applink

Is there a way to log content to a memory stream (buffer) not to a file?

https://stackoverflow.com/questions/76621500/openssl-fatal-openssl-uplink5c149000-08-no-openssl-applink-in-c-sharp-wrap

lsh123 commented 3 months ago

If you can reproduce the issue with xmlsec command line utility then it would be easier to debug it. Use --print-debug flag to trigger xmlSecDSigCtxDebugDump usage. As of now, I stand by my comment above about mismatch between headers / compile flags and library version. Using xmlsec command line utility would guarantee that compilation / linking is consistent.

lsh123 commented 3 months ago

oh I missed it: "I used fopen and fclose function statically linked to open and close Log file". Of course this is going to crash. Welcome to Microsoft runtimes hell. Question 2.7 in the FAQ (https://www.aleksey.com/xmlsec/faq.html).

dg0yt commented 3 months ago

oh I missed it: "I used fopen and fclose function statically linked to open and close Log file". Of course this is going to crash. Welcome to Microsoft runtimes hell. Question 2.7 in the FAQ (https://www.aleksey.com/xmlsec/faq.html).

Well, runtimes hell is what vcpkg tries to eliminate AFAIU. There are even post-build checks. So I wouldn't be surprised if executables from the ports just work.
But does the user project use the same configuration as the ports? And does OPENSSL_Applink have a meaning here?