You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oozie.apache.org by "Sanjay Kumar Sahu (Jira)" <ji...@apache.org> on 2023/09/14 21:23:00 UTC
[jira] [Updated] (OOZIE-3719) Apache Oozie Regex Denial of Service (ReDoS) Vulnerability by Low Privilege Users Disrupting Access for Intended Users
[ https://issues.apache.org/jira/browse/OOZIE-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sanjay Kumar Sahu updated OOZIE-3719:
-------------------------------------
Description:
!image-2023-09-15-02-47-52-819.png!
Looking further into the code focusing on the action and type query strings.
We can see that the filter variable is getting its value from the requestsParameters .
once the Filter parameter is being populated, an If loop checking whether Scope and Type are not Null and next
the code checks the logRetrievalType is equal to the JOB_LOG_ACTION (which is the action query string).
Next the values of logRetrievalScope gets split by , and entering the the if loop.
In the block where ranges of actions are processed ( if (s.contains("-")) \{ ... } ), an attacker could potentially
send a specially crafted request with a massive range, such as "1-1000000". This would create a for loop
iterating and adding that many actions to the actionSet , consuming CPU and memory resources.
Though there is a subsequent check against maxNumActionsForLog , this check only happens after all the iterations,
allowing an attacker to consume resources before this check is made -
!image-2023-09-15-02-52-09-320.png!
was:
!image-2023-09-15-02-47-52-819.png!
Looking further into the code focusing on the action and type query strings.
We can see that the filter variable is getting its value from the requestsParameters .
once the Filter parameter is being populated, an If loop checking whether Scope and Type are not Null and next
the code checks the logRetrievalType is equal to the JOB_LOG_ACTION (which is the action query string).
Next the values of logRetrievalScope gets split by , and entering the the if loop.
In the block where ranges of actions are processed ( if (s.contains("-")) \{ ... } ), an attacker could potentially
send a specially crafted request with a massive range, such as "1-1000000". This would create a for loop
iterating and adding that many actions to the actionSet , consuming CPU and memory resources.
Though there is a subsequent check against maxNumActionsForLog , this check only happens after all the iterations,
allowing an attacker to consume resources before this check is made -
!image-2023-09-15-02-50-26-331.png!
> Apache Oozie Regex Denial of Service (ReDoS) Vulnerability by Low Privilege Users Disrupting Access for Intended Users
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: OOZIE-3719
> URL: https://issues.apache.org/jira/browse/OOZIE-3719
> Project: Oozie
> Issue Type: Bug
> Components: core
> Affects Versions: 5.2.1
> Reporter: Sanjay Kumar Sahu
> Priority: Major
> Attachments: image-2023-09-15-02-47-52-819.png, image-2023-09-15-02-49-14-531.png, image-2023-09-15-02-52-09-320.png
>
>
> !image-2023-09-15-02-47-52-819.png!
>
> Looking further into the code focusing on the action and type query strings.
> We can see that the filter variable is getting its value from the requestsParameters .
> once the Filter parameter is being populated, an If loop checking whether Scope and Type are not Null and next
> the code checks the logRetrievalType is equal to the JOB_LOG_ACTION (which is the action query string).
>
> Next the values of logRetrievalScope gets split by , and entering the the if loop.
> In the block where ranges of actions are processed ( if (s.contains("-")) \{ ... } ), an attacker could potentially
> send a specially crafted request with a massive range, such as "1-1000000". This would create a for loop
> iterating and adding that many actions to the actionSet , consuming CPU and memory resources.
> Though there is a subsequent check against maxNumActionsForLog , this check only happens after all the iterations,
> allowing an attacker to consume resources before this check is made -
>
> !image-2023-09-15-02-52-09-320.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)