Shibd crash

I'm seeing this nesting problem using Apache XML Security, but it is not benign. Although the XML encrypted file can be decrypted in Java, it will not decrypt in .Net. .Net raises this error: "[CryptographicException: Unable to retrieve the decryption key.]" Seems to mess up the parsing. By manually editing the encrypted document (moving X509Data inside the Encrypted Key element, and wrapping the X509Data element in a second KeyInfo element), all becomes well, so it does appear to be the same type of problem.

—

Scott Cantor added a comment - 25/Jun/09 05:08 PM
Lots of fun here...was investigating another aspect of the message and there's another bug in the IdP. It's including the public key of the SP in the message by placing the X509Data element containing the certificate next to the EncryptedKey element instead of as a child element of a KeyInfo element inside the EncryptedKey.

This doesn't prevent decryption, but it violates the proper layout causing additional work for the SP, and is nonsensical from an XML Encryption point of view.

In other words, it's sending this:

EncryptedData
KeyInfo
EncryptedKey
X509Data (with SP's key)

The correct nesting is this:

EncryptedData
KeyInfo
EncryptedKey
KeyInfo
X509Data (with SP's key)

There is a small chance this is related to your crash (which would still be a bug in the SP), but I doubt it.

If you need additional help, please use the mailing list. In terms of your metadata, I don't know why I can't verify the signature, but if it works on your end that's fine. I will say you have a bug in your configuration caused by improperly stripping rules out of the SecurityPolicy at the bottom. You need to start over with a standard configuration to avoid security holes in your system.

With respect to the patch, I would suggest you NOT try to fix the problem other than by getting the IdP to stop sending a broken/invalid encryption message, but building a patched version requires checking out the branch from subversion and building it from source (or generating an RPM from that).

Scott,

I've send you the IDP metadata file I use. Do you wan't my shibboleth2.xml file too?
You'll find in attachment the shibd.log file from latest tests (which have generated the last stack trace when shibd crashes).

As you'll see, I didn't see any WARN message. Maybe the base64 file incorrect? I cannot send assertion myself with a browser. So, how can I do in order to get the assertion sending by the browser? For the moment, I copy/paste the decoded assertion from the shibd.log file the encode it in base 64...

How to use the patch you generated? By replacing the files in SRPM file and build the package again?

Thanks a lot for the debug works.

http://svn.middleware.georgetown.edu/view/cpp-xmltooling?view=rev&revision=599

The bug is in xmltooling and is caused by a failure to clean up a pointer when a related object is deleted.

The trigger for this is the incorrect KeyInfo structure the IdP is producing that I described up above in a comment. It causes the decryption code to extract a public key from the top level KeyInfo object inside EncryptedData, which is useless since the encryption key is a wrapped symmetric key. That results in the code dropping into the key decryption routine, which then processes the EncryptedKey element and looks for a KeyInfo inside it. Since there is no such child, it "clears" the KeyInfo from an internal object, but fails to dispose of the pointer to the public key it extracted earlier, and continues to use it, resulting in a crash because the pointer is to a deleted object.

I'm moving the issue to xmltooling since that's the actual spot of the bug.