Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Mon, 18 Nov 2013 14:19:26 +0000 (UTC)
From: "Sergey Beryozkin (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12679491.1384550269016.90403.1384784366528@arcas>
In-Reply-To: <JIRA.12679491.1384550269016@arcas>
References: <JIRA.12679491.1384550269016@arcas>
Subject: [jira] [Resolved] (CXF-5390) AbstractSamlBase64InHandler goes into
 infinite loop when processing bad header value.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CXF-5390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sergey Beryozkin resolved CXF-5390.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 2.6.11
                   2.7.8
                   3.0.0
         Assignee: Sergey Beryozkin

Thanks for reporting it and actually identifying the source of the problem.

> AbstractSamlBase64InHandler goes into infinite loop when processing bad header value.
> -------------------------------------------------------------------------------------
>
>                 Key: CXF-5390
>                 URL: https://issues.apache.org/jira/browse/CXF-5390
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 2.7.3
>         Environment: Linux or Mac, Karaf 2.3.1 container, CXF 2.7.3
>            Reporter: Dario Amiri
>            Assignee: Sergey Beryozkin
>            Priority: Critical
>             Fix For: 3.0.0, 2.7.8, 2.6.11
>
>
> Let's say I protect my JAX-RS service using SamlHeaderInHandler. The service expects me to include a valid deflate encoded (compressed) then base 64 encoded token in the Authorization of my RESTful call like this:
> SAML <TOKEN GOES HERE>
> However if instead of inserting a token, I insert the following string "invalid_grant" in the Authrorization header like so:
> SAML invalid_grant
> The following will happen:
> 1. SamlHeaderInHandler splits the header into it's two parts and sends what it thinks is the assertion (the "invalid_grant" string) AbstractSamlBase64InHandler.handleToken
> 2. AbstractSamlBase64InHandler.handleToken first base 64 decodes the string. This completes with no error.
> 3. AbstractSamlBase64InHandler.handleToken then tries to inflate the assertion.
> It is during this last step that CXF goes into an infinite loop. Here is the code involved:
>         while (!inflater.finished()) {
>             inputLen = inflater.inflate(input);
>             if (!inflater.finished()) {
>                 inflatedToken = new byte[input.length + inflatedLen];
>                 System.arraycopy(input, 0, inflatedToken, inflatedLen, inputLen);
>                 inflatedLen += inputLen;
>             }
>         }
> When the input is the following byte array:
> [94, -27, -122, 110, 16, 59, 41, 43, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
> (which is the result from base 64 decoding the string "invalid_grant")
> The loop never breaks because the test inflater.finished() is never true even if inputLen is 0. Thus the service hangs indefinitely.
> I am classifying this as Critical because, essentially, by crafting a certain type of request, I can execute a denial of service attack against the service.


--
This message was sent by Atlassian JIRA
(v6.1#6144)