Re: possible DoS attack

It would seem sensible to me for toolkits to limit search depths (in a
configurable fashion) and to detect infinite loop conditions where
practical.  Given the magical things one can do with URIs, I think one can
create infinite loops that are NOT easily detectable by Toolkits so a
configurable search depth limit seems the best, sufficient approach I can
think of offhand.

Regards, Ed

----- Original Message -----
From: "Blair Dillaway" <blaird@microsoft.com>
To: <aleksey@aleksey.com>; <xml-encryption@w3.org>
Sent: Thursday, April 11, 2002 1:02 PM
Subject: RE: possible DoS attack


> 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
> WG.
>
> Blair
>
> -----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#'>
>         <EncryptionMethod
> Algorithm='http://www.w3.org/2001/04/xmlenc#aes128-cbc'/>
>             <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
>                 <ds:RetrievalMethod URI='#EK'
> Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
>            </ds:KeyInfo>
>         <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData>
>     </EncryptedData>
>     <EncryptedData Id='EK' xmlns='http://www.w3.org/2001/04/xmlenc#'>
>         <EncryptionMethod
> Algorithm='http://www.w3.org/2001/04/xmlenc#aes128-cbc'/>
>             <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
>                 <ds:RetrievalMethod URI='#ED'
> Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
>            </ds:KeyInfo>
>         <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData>
>     </EncryptedData>
>
>
> 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
> special
> 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
> http://www.aleksey.com/xmlsec
>
>
>
>
>
>

Received on Thursday, 11 April 2002 13:47:37 UTC