cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CXF-5390) AbstractSamlBase64InHandler goes into infinite loop when processing bad header value.
Date Mon, 18 Nov 2013 14:19:26 GMT

     [ 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)

Mime
View raw message