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