W3C home > Mailing lists > Public > xml-encryption@w3.org > April 2002

RE: possible DoS attack

From: Blair Dillaway <blaird@microsoft.com>
Date: Thu, 11 Apr 2002 10:02:13 -0700
Message-ID: <AA19CFCE90F52E4B942B27D42349637902CDCF9E@red-msg-01.redmond.corp.microsoft.com>
To: <aleksey@aleksey.com>, <xml-encryption@w3.org>
In your example, the RetrievalMethod indicates you are to retrieve an
EncryptedKey.  Shouldn't your code immediately error when it finds the
target of the URI is an EncryptedData?

In any event, we had a fairly long discussion on DoS issues when this
activity started and realized there is no way to prevent them and also
meet our goal of creating a general purpose and flexible system.  Its
fairly easy to construct examples that will cause a recipient to very
deeply recurse (possibly infinite) looking for a decryption key.  I
suppose one could support an application defined recursion limit to try
and bound this problem, but addressing DoS attacks was not a goal of the


-----Original Message-----
From: Aleksey Sanin [mailto:aleksey@aleksey.com] 
Sent: Thursday, April 11, 2002 9:44 AM
To: xml-encryption@w3.org
Subject: possible DoS attack

Hi, All!

I think I found a possible DoS attack  on the application that uses XML
Encryption and I would like to get your opinion on how real is it.

Suppose the application processes encrypted requests (for example, SAML
requests) from end-users ("rich clients" like ICQ, AIM, etc.). And the
"bad guy" submits following XML document:

    <EncryptedData Id='ED' xmlns='http://www.w3.org/2001/04/xmlenc#'>
            <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
                <ds:RetrievalMethod URI='#EK' 
    <EncryptedData Id='EK' xmlns='http://www.w3.org/2001/04/xmlenc#'>
            <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
                <ds:RetrievalMethod URI='#ED' 

As you can see the <ds:RetrievalMethod /> from the first <EncryptedData 
/> points
to the second <EncryptedData /> and the the <ds:RetrievalMethod /> from 
the second
<EncryptedData /> points to the first <EncryptedData />.
If the application will try to decrypt such message and will do no 
special processing then it
will end up in an infinite loop. And "bad guy" will effectivly cause
DoS. This example is simple and probably it's pretty simple to have
check for this case.
However, the real attack can include XPath, XSLT and other transforms 
and this will
make check very complicated.  The other solution is to put a simple "max

lookup depth" check
(do not do more than 10 retrievals, for example).

The similar attack is possible to incorrect XMLDsig implementations (if 
the implementation
executes second level <ds:RetrievalMethod />). But in XMLDSig case the 
standard itself
does not allow it. The XML Enc standard does not prevent this attack and

I think it's worth
to put some kind of warning for implementors.

Aleksey Sanin.
XML Security Library
Received on Thursday, 11 April 2002 13:02:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:03 UTC