[
https://issues.apache.org/jira/browse/ZOOKEEPER-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15865085#comment-15865085
]
Michael Han commented on ZOOKEEPER-2693:
----------------------------------------
One option is to enable TLS for ZooKeeper client-server communication. Because
TLS is on a different port (secureClientPort) than the four letter words port
(clientPort), we can then put clientPort behind a firewall which effectively
makes only admin (or whoever that's trusted) can execute four letter words.
This however does not address the issues completely, because TLS is only
supported since ZooKeeper 3.5.1 so it would not work for 3.4.x. Also even with
TLS presence, it might still be possible that a ZooKeeper ensemble is attacked
as long as the ensemble is open to the world: we don't have rate limiting built
in, so if a set of rogue clients making connection requests, when in large
scale, could possibly keep ensemble too busy to serve other requests. Although
we do have IP based authentication scheme we don't have any rate limiters
implemented to enforce accesses in such case.
I believe the original design consideration for ZooKeeper was that ZooKeeper
ensembles should only be accessible from a trusted computing environment
instead of opening to the world. This design decision made perfect sense in the
Hadoop context but might not be ideal given today's thread models (e.g., it is
never safe to trust any network communication, attackers exist inside the
corporate network, and so on.). As such, we may need to change the assumption
on where ZooKeeper is going to be deployed and operated, but before that, to
address this specific issue documented in the JIRA, we could do a combination
of:
* As Patrick suggested, add configurations options to turn off four letter
words and / or specific commands.
* Document explicitly the recommended security practice on deploy and operate
ZooKeeper - basically admin should not leave the ZK wide open to the world.
I think a patch contain both should be enough for resolving the current issue.
In long term, we need reevaluate the design decisions and security thread
models and to bridge the gap between the current design and what ZooKeeper is
actually used in prod today (e.g. adding rate limiter, enforced access control,
not just for TLS but also for Kerberos, like what ZOOKEEPER-1634 is trying to
solve.).
> 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
> Reporter: Patrick Hunt
> 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)
