zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Han (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (ZOOKEEPER-2693) DOS attack on wchp/wchc four letter words (4lw)
Date Thu, 16 Feb 2017 23:40:42 GMT

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

Michael Han edited comment on ZOOKEEPER-2693 at 2/16/17 11:40 PM:
------------------------------------------------------------------

bq. Can we restrict 4lw commands based on IP By default we can allow access to the IP on which
server is running.
[~arshad.mohammad] Thanks for feedback, this is one way of addressing the issue. I still prefer
the current command white list approach because:
* It has a smaller scope than the IP-restriction based approach. It is simpler, less cases
to test, and easier to understand.
* One case about IP based approach - what if the access point which IP is white listed gets
compromised and admins are not aware of such case (so reconfigure the IP white list will not
be done in time)? In that case, this exploit is still possible from the compromised and white
listed access point. On the other side, the command white list approach does not have this
issue, if the watcher monitoring commands listed in this issue are not white listed, there
is no way to exploit. 

Overall I think the IP white list approach is a nice to have as it provides the option to
use the entire sets of commands while mitigating the potential risk of being exploited - while
the command white list approach is a must have based on my previous arguments. I propose we
get the command white list patch in, and then the release out, and then think about how to
improve the overall access control of ZK in the wild, unless the current command white list
does not address the security concern raised by this JIRA. 



was (Author: hanm):
bq. Can we restrict 4lw commands based on IP By default we can allow access to the IP on which
server is running.
[~arshad.mohammad] Thanks for feedback, this is one way of addressing the issue. I still prefer
the current white list approach because:
* It has a smaller scope than the IP-restriction based approach. It is simpler, less cases
to test, and easier to understand.
* One case about IP based approach - what if the access point which IP is white listed gets
compromised and admins are not aware of such case (so reconfigure the IP white list will not
be done in time)? In that case, this exploit is still possible from the compromised and white
listed access point. On the other side, the command white list approach does not have this
issue, if the watcher monitoring commands listed in this issue are not white listed, there
is no way to exploit. 

Overall I think the IP white list approach is a nice to have as it provides the option to
use the entire sets of commands while mitigating the potential risk of being exploited - while
the command white list approach is a must have based on my previous arguments. I propose we
get the command white list patch in, and then the release out, and then think about how to
improve the overall access control of ZK in the wild, unless the current command white list
does not address the security concern raised by this JIRA. 


> DOS attack on wchp/wchc four letter words (4lw)
> -----------------------------------------------
>
>                 Key: ZOOKEEPER-2693
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2693
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: security, server
>    Affects Versions: 3.4.0, 3.5.1, 3.5.2
>            Reporter: Patrick Hunt
>            Assignee: Michael Han
>            Priority: Blocker
>             Fix For: 3.4.10, 3.5.3
>
>
> The wchp/wchc four letter words can be exploited in a DOS attack on the ZK client port
- typically 2181. The following POC attack was recently published on the web:
> https://webcache.googleusercontent.com/search?q=cache:_CNGIz10PRYJ:https://www.exploit-db.com/exploits/41277/+&cd=14&hl=en&ct=clnk&gl=us
> The most straightforward way to block this attack is to not allow access to the client
port to non-trusted clients - i.e. firewall the ZooKeeper service and only allow access to
trusted applications using it for coordination.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message