Closed relaxnow closed 9 years ago
This issue depends on simplesamlphp/simplesamlphp#139
However, we could probably vastly reduce its impact by upgrading to SSP 1.13.2 as base SSP, which has the c14n fix that makes xml parsing much less resource intensive.
Good idea in any case
I'm wondering whether this attack vector could be used to cause a denial of service in other parts of SSP. I can imagine for instance simulating an IdP-initiated login to send a SAML response directly to the AssertionConsumerService, then crafting that response to dramatically increase its size (i.e.: adding XML elements inside an attribute value) and sending it over again and again until the server chokes. Probably there's even no need to send valid SAML responses (even SAML messages), as in order to consume a response the first thing you need to do is to parse the XML document, and that's the computationally intensive operation here.
Have you considered any scenarios like that? The C14N fix to xmlseclib would definitely help, but in any case it would be a matter of increasing the size of the XML document sent to SSP.
The size of the XML document you can send to SSP is limited by post_max_size which is 8MB by default. So maybe with the C14N fix you're already quite safe.
Yes, I was thinking about that too, but 8MB is quite a lot to digest for an XML chunk, even with the canonicalization fix. Unfortunately I see no easy way to assess a problem like this. I can imagine legitimate scenarios involving SAML responses with a size of that order of magnitude (i.e.: including high-res pictures of the user), so you cannot just hard-limit the expected size of the assertion, nor in the code, nor in the PHP config.
I guess this should be left to the underlying infrastructure to detect and react in case of DoS attacks.
Agreed. I think SSP and xmlseclibs have done what they can to limit the impact on their side. Further mitigations are in the domain of the infrastructure.
Vulnerability ID: SUR-705 Vulnerability Type: Denial of service Threat Level: Low
Description
Large POST requests may be used to rapidly consume server resources.
Technical Details
When sending a POST request containing 8355838 bytes of XML data the server responds with an error:
It seems to be trying to allocating 134MB of memory for an 8MB request. This may be abused as a memory exhaustion DoS attack since the page is public.
Impact
Unavailability of services, dependent on the server configuration and which other services may be on the same machine.
Recommendation
The metadata converter service probably should not be publicly accessible, as it is located under the /admin/ folder. The request size should be limited for unauthenticated users.