Bugzilla – Bug 1094134
VUL-1: CVE-2018-8012: zookeeper: No authentication/authorization is enforced when a server attempts to join aquorum
Last modified: 2024-07-26 09:46:11 UTC
CVE-2018-8012 No authentication/authorization is enforced when a server attempts to join a quorum in Apache ZooKeeper before 3.4.10, and 3.5.0-alpha through 3.5.3-beta. As a result an arbitrary end point could join the cluster and begin propagating counterfeit changes to the leader. VUL-1 since I assume that we firewall this anyway. Should take this with the next regular update and harden our configuration References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-8012 http://seclists.org/oss-sec/2018/q2/132 http://www.cvedetails.com/cve/CVE-2018-8012/ https://lists.apache.org/thread.html/c75147028c1c79bdebd4f8fa5db2b77da85de2b05ecc0d54d708b393@%3Cdev.zookeeper.apache.org%3E
This issue is also tracked at https://trello.com/c/ZbvIclVA/990-bug-1094134-cve-2018-8012-vul-1-cve-2018-8012-zookeeper-no-authentication-authorization-is-enforced-when-a-server-attempts-to-jo
We need to modify the monasca barclamp in SOC 7 to add the necessary configuration option. I'll put up a pull request for this change.
SOC 6 does not come with Monasca
(In reply to Nicolas Bock from comment #3) > We need to modify the monasca barclamp in SOC 7 to add the necessary > configuration option. I'll put up a pull request for this change. I was wrong here, we are not doing much in the barclamp code and am using the monasca installer to pull in all of the packages. So we can either modify the installed zookeeper configuration file after installation or try to get the additional options into the upstream zookeeper repository.
One of the indirect suggestions for mitigation is using DIGEST-MD5, but that might not work because of its problems. I reported this upstream as https://issues.apache.org/jira/browse/ZOOKEEPER-3069
I am currently investigating the Kerberos based setup.
In SOC 7 the zookeeper instance is tied to the `monasca-server` role which can only be deployed on one server as the monasca barclamp is not HA enabled. This makes a fix for SOC 7 potentially a little easier: We enable DIGEST-MD5 SASL for the single zookeeper instance. Any security concerns with regard to DIGEST-MD5 are irrelevant in this case since we can not have a second zookeeper instance. Any second zookeeper would be unauthorized. Could the security team comment on this strategy?
We should modify the config file we get from upstream to not listen for other quorum members since there can be no other valid members the way we deploy zookeeper in SOC 7. As defense in depth we should also block the port used for elections with a firewall rule. In this way more than one mistake is required before an attacker could exploit the lack of authentication to cause trouble. In the future if we actually use elections then we will need to configure proper authentication, but that is not required today for adequate mitigation of this vulnerability given the way we deploy zookeeper in SOC 7.
To clarify, I mean a firewall rule on the zookeeper node itself, not a firewall rule on some firewall protecting access to the admin network (although that rule should also exist). Whenever possible we want to avoid making the assumption that no malicious people or software are ever on the admin network, and defend against attacks which originate on the admin network to the extent it is feasible to do so.
The documentation https://zookeeper.apache.org/doc/current/zookeeperAdmin.html mentions that quorumListenOnAllIPs is false by default and thus it listens only on interfaces needed to connect to the its peers configured with the server list. Maybe that can be used to make it not listen.
We need to understand if there are separate ports used for the communication with peers and the other things zookeeper does. If so we can probably not listen on the ports used for peer communication since there should be no peers. If not then we need to come up with a different plan to address this vulnerability.
(In reply to Nicolas Bock from comment #8) > In SOC 7 the zookeeper instance is tied to the `monasca-server` role which > can only be deployed on one server as the monasca barclamp is not HA > enabled. This makes a fix for SOC 7 potentially a little easier: > > We enable DIGEST-MD5 SASL for the single zookeeper instance. > > Any security concerns with regard to DIGEST-MD5 are irrelevant in this case > since we can not have a second zookeeper instance. Any second zookeeper > would be unauthorized. How would we ensure that this particular usage is not enabled for HA later? I am trying to find the change that was implemented in the end?
(In reply to Andreas Stieger from comment #13) > I am trying to find the change that was implemented in the end? Hi Andreas, unfortunately, I was moved into another team before this came to a resolution.
Has anyone checked on a SOC7 deploy if the ports are already blocked, or aren't open? Quick test procedure (I don't have a SOC7 system or I'd test myself): - sudo netstat -paen | less - search for port 2181 (the standard client connection port, must be open) - identify the process number listening on 2181 - search for any other listening ports with the same process number According to the https://zookeeper.apache.org/doc/r3.4.10/zookeeperStarted.html doc, the other way to identify server connection ports is in zoo.cfg and they appear to be around 2888 and 3888 (not sure what Crowbar configures for these).
Note https://build.suse.de/package/show/SUSE:SLE-12-SP4:Update:Products:Cloud9/zookeeper looks like version 3.4.9 I'll also mention https://zookeeper.apache.org/security.html has links to https://issues.apache.org/jira/browse/ZOOKEEPER-1045 https://cwiki.apache.org/confluence/display/ZOOKEEPER/Server-Server+mutual+authentication http://zookeeper.apache.org/doc/current/zookeeperAdmin.html
All done, closing.