[jira] [Commented] (CXF-6479) Denial of Service: Regular Expression in StringUtils

["Sergey Beryozkin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CXF-6479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608157#comment-14608157 ] 

Sergey Beryozkin commented on CXF-6479:
---------------------------------------

message.getContextualProperty consumes the data provided in the application configuration so I doubt this can qualify as a DOS issue as it s not a bad client that is driving it, and if we assume that the actual deployment environment which supports the application with the configuration is untrusted then obviously the security has already been compromised.

However, I'll update the code slightly to make sure the custom separator, if provided, has a length of 1 char.

> Denial of Service: Regular Expression in StringUtils
> ----------------------------------------------------
>
>                 Key: CXF-6479
>                 URL: https://issues.apache.org/jira/browse/CXF-6479
>             Project: CXF
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.1.1
>            Reporter: Donald Kwakkel
>
> Untrusted data is passed to the application and used as a regular expression.  This can cause the thread to over-consume CPU resources.
> org.apache.cxf.common.util.StringUtils    
> {code}
>             String separator = getSeparator();
>             return StringUtils.split(c, separator);
> {code}
> Where separator is provided by CacheControlHeader:
> {code}
> Object sepProperty = message.getContextualProperty(CACHE_CONTROL_SEPARATOR_PROPERTY);
> {code}
> There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating repeating and alternating overlapping of nested and repeated regex groups. This defect can be used to execute a DOS (Denial of Service) attack.
> Example:
>     
>         (e+)+
>         ([a-zA-Z]+)*
>         
>         There are no known regular expression implementations which are immune to this vulnerability.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)