What to do about Xalan?

[Cantor, Scott]

I've been investigating the risk to the Shibboleth SP of the XML Encryption attack that was recently identified in Java [1] and one of the vectors I was digging into was the XSLT threat.

The official SP story is "you should really never build Santuario against Xalan when using it for the SP", and none of my packages do, obvkiously. And Xalan is almost as dead, if not moreso, than Xerces, so it's not even a responsible decision to ship it anymore.

Unfortunately, it appears Debian's SP packaging builds xml-security-c against Xalan. That is a bad idea, though I understand why someone might have done it.

In terms of threat, it's not at the level of the unpatched Java risk. The Xalan in Java has the ability to use standard XSLT extensions to call into arbitrary Java classes. The C++ version isn't, as far as I can see, so insane as to allow just doing exec() calls, so it's more constrained, you have to register functions implemented at runtime to use them, it's not arbitrary.

That said, I have to do something here. Eventually the SP is gonna be patched to deal with this, but I was hoping to avoid it in the short term because absent XSLT support and remote URI lookup, the risk is pretty low. But unfortunately you handed it XSLT support, so the risk is higher to at least play games and the more games you can play...

Anyway, partly this is an FYI and partly a request to consider whether you should issue package an update to your packaging of xml-security-c that avoids Xalan, or perhaps add a split package and have the SP depend on the "without" one?

I am hesitant to call this a security issue right now. I think it's more of a warning that this is a really bad idea to leave it in this state for the moment.

But I will probably get working on a patch to lock out the attack vector in xmltooling so if you prefer to wait for that, that's not the end of the world.

-- Scott 

[1] https://shibboleth.net/community/advisories/secadv_20221216.txt