search

janus-ssp / janus

Fully featured metadata registration administration module built on top of simpleSAMLphp.
Other
13 stars 8 forks source link

SUR-705 – Denial of service #556

Closed relaxnow closed 9 years ago

relaxnow commented 9 years ago

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:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 33416582 bytes) 
in /opt/www/OpenConext-serviceregistry/vendor/simplesamlphp/simplesamlphp/templates/metadata-converter.php on line 35 
Call Stack: 
0.0001 25697112 1. {main}() 
  /opt/www/OpenConext-serviceregistry/vendor/simplesamlphp/simplesamlphp/www/admin/metadata-converter.php:0 
0.3454 81835880 2. SimpleSAML_XHTML_Template->show() 
  /opt/www/OpenConext- serviceregistry/vendor/simplesamlphp/simplesamlphp/www/admin/metadata-converter.php:63
0.3457 81838416 3. require_once('/opt/www/OpenConext-serviceregistry/vendor/simplesamlphp/simplesamlphp/templates/metadata- converter.php') 
  /opt/www/OpenConext-serviceregistry/vendor/simplesamlphp/simplesamlphp/lib/SimpleSAML/XHTML/Template.php:575 
0.5384 107191112 4. htmlspecialchars() 
  /opt/www/OpenConext-serviceregistry/vendor/simplesamlphp/simplesamlphp/templates/metadata-converter.php:35

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.

thijskh commented 9 years ago

This issue depends on simplesamlphp/simplesamlphp#139

thijskh commented 9 years ago

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.

relaxnow commented 9 years ago

Good idea in any case

relaxnow commented 9 years ago

Upgrade applied in https://github.com/SURFconext/SURFconext-deploy/commit/c33c1d24231a167aee0b3d8773bead2066a2dc42

jaimeperez commented 9 years ago

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.

thijskh commented 9 years ago

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.

jaimeperez commented 9 years ago

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.

thijskh commented 9 years ago

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.