Check XMLSec vulnerability within Lasso integration
Le mercredi 26 octobre 2011 à 08:53 +0200, Clément OUDOT a écrit :
- Masquer le texte des messages précédents -
2011/10/25 Mikaël Ates firstname.lastname@example.org:
Thank you to have post this alert on the list.
The encrypted elements with W3C XMLEnc handled in Lasso are EncryptedAssertion and EncryptedID. The material for EncryptedAttribute is present but not yet used in the assertion processing. So I limit my answer to these two elements for the SAML2 Authnrequests for now.
The attack described  is based on the decryption server used as an oracle.
So the first thing is that the signature verification first prevent to treat crafted messages for entities other that the IdPs trusted by the SP:
- response signature is checked before assertion decryption
- assertion signature is checked before nameId decryption
So we may consider this threat limited to rogue IdPs. For instance a rogue IdP intercepts a response provided to an SP by a third IdP and use the SP as an oracle to decrypt it.
The attack relies on the Oracle answers, especially on an XMLEnc error message given when there is a padding error or an invalid character in plain text. The advise given by authors is thus to provide unified error messages to mislead oracle functions. That means that a same error message returned should cover the XMLEnc security error and application level errors.
Lasso relies on xmlsec as an implementation of XMLEnc. The samlxec function xmlSecEncCtxDecrypt() is used, which returns a negative value if an error occurs, error including a padding error or an invalid character in the plain text decrypted.
Lasso uses the decryption function lasso_node_decrypt_xmlnode() that returns LASSO_DS_ERROR_DECRYPTION_FAILED if the xmlsec function xmlSecEncCtxDecrypt() returns a negative value. This error is also returned by lasso_node_decrypt_xmlnode() when there is no encryption method in encryptionData, a missing Algorithm, an unknown encryption method or a missing encrypted key node.
When Lasso tries to decrypt assertions it handles multiple encrypted assertions. And if at least one assertion can be decrypted, no error is raised. If no assertion is decrypted, because for each assertion, there is an error in:
- a missing key,
- a malformed xml sec element,
- a lasso_node_decrypt_xmlnode() error,
- a malformed assertion, it results in a missing assertion in the response, the error LASSO_PROFILE_ERROR_MISSING_ASSERTION is returned by Lasso. How this error is handled is implementation dependant.
When Lasso tries to decrypt an EncryptedID element, if xmlsec returns an error, Lasso returns LASSO_DS_ERROR_DECRYPTION_FAILED. How this error is handled is implementation dependant.
In both case, this should result in a not qualified error message given in the HTTP response to the browser.
Hope it helps,
thanks a lot for this very sharp answer, but as I am really not an XMLSec expert, I just understand that the only impact for Lasso is that it will return a LASSO_DS_ERROR_DECRYPTION_FAILED error. So, for softwares using Lasso, nothing to do if we already manage Lasso errors? Hi,
The implementations using Lasso must take care that: 1- With encrypted assertions, response should be signed. 2- When the authnresponse processing fails, the kind of error should not be returned in the HTTP response given to the browser.