CVE-2023-34205: Critical security vulnerability · Issue #23 · moov-io/signedxml

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

elwint opened this issue

Jan 18, 2023

· 12 comments · Fixed by #25

Closed

Critical security vulnerability #23

elwint opened this issue

Jan 18, 2023

· 12 comments · Fixed by #25

Comments

I would like to report a potentially critical security vulnerability, however I couldn’t find a way to contact you. Could you please provide contact details?

@elwint did you hear back? I’m curious what you found.

@adamdecaf I haven’t heard back from him regarding the vulnerability. He only told me he hasn’t been actively maintaining/using this library for a while.

My recommendation would be to use a more established library for signature validation, e.g. https://github.com/russellhaering/goxmldsig

@ma314smith What are your plans for this library? I will disclose more information about the vulnerability next week.

elwint changed the title Potentially critical security vulnerability Critical security vulnerability

Mar 24, 2023

Thanks @elwint, I’ve tried using goxmldsig and haven’t had luck. It’s a bit too specific for SAML and my use-case fails validation. We’re working on a fork/update to goxmldsig, but that isn’t very active either.

@adamdecaf as you suggested in your PR, I’m open to handing this off if you’re interested.

I can forward you the info from @elwint and you can decide. Sounds like maybe it wasn’t as critical as initially thought.

@ma314smith Thanks for your reply, but note to other users, the vulnerability is critical if the signed payload returned by ValidateReferences is not used, or if the deprecated Validate function was used, and the document is parsed by Go’s XML unmarshaller.

Thanks, yes this looks to be mostly resolved with ValidateReferences. Callers need to check/use the returned references though.

@adamdecaf I think the vulnerability is still present and should be properly mitigated, the deprecated Validate function still exists, which should be removed (also in the readme). The references returned by ValidateReferences are not always checked/used by callers, so perhaps something can be implemented to mitigate the attack. Can you also create a GitHub security advisory to inform users about the vulnerability?

adamdecaf added a commit that referenced this issue

Apr 21, 2023

I’ve removed references to .Validate() in the readme and tests, but I am seeing one case where ValidateReferences() returns a ref I don’t think it should. Do you have a better example for checking references?

We can create a security advisory on pre-1.0 releases. We’re planning a 1.0 release soon.

@elwint could you provide more background and details on what security vulnerability exists. @adamdecaf and I are very interesting in fixing any vulnerabilities. With regards the Validate() and ValidateReferences() methods, the validate() method validates signed XML. It does this by applying some transforms to the xml that canonicalize it before checking the signature. If the validation succeeds, then XML received is guaranteed to semantically match what was signed. The strings returned from the ValidateReferences() method are just the canonicalized XML. Nothing in the canonicalization process changes the semantics of the XML, so once a signature is validated there is no reason to use the canonicalized XML as opposed to the received XML. They both represent the same information. @elwint is this at all related to your concerns?

@adamdecaf I’m not sure what would be the best way to mitigate the attack without affecting legitimate use. However, the same attack doesn’t work in goxmldsig because it always checks if the signature is referencing the top-element of the XML. Perhaps something similar can be implemented?

@rowland66 The vulnerability exists when the received XML is parsed by Go’s XML unmarshaller, instead of the signed payload returned by ValidateReferences. Parsing the received raw XML can result in a different output than parsing the signed payload/canonicalized XML. This makes it possible to bypass the signature validation using a Signature Wrapping attack (XSW). Adam should’ve received an email earlier containing more information about the vulnerability and a PoC that exploits the vulnerability.

Because a signature validation bypass is possible when the deprecated Validate function is used, it should be removed entirely. This may be a breaking change, but at least it cannot be used anymore.

Because a signature validation bypass is possible when the deprecated Validate function is used, it should be removed entirely. This may be a breaking change, but at least it cannot be used anymore.

Agreed.