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