Bug#990345: zookeeper: various security issues
Further for the records (for a future upgrade to newer ZK versions): There will likely need to be a NEWS.Debian entry about the following: https://issues.apache.org/jira/browse/ZOOKEEPER-3056 In short: - apparently they've added a check that prevents ZK from starting, when no snapshots were found in the dataDir - the workaround is to ONCE set snapshot.trust.empty=true (the zookeeper.snapshot.trust.empty=true mentioned in most messages of the bug does not work, which is mentioned in some later answers) - start up the server - remove the setting again quoting: "It is recommended to remove the property once you have a working server, because that check is important to ensure that the system is in good shape" Cheers, Chris.
Bug#990345: zookeeper: various security issues
On Fri, Jul 16, 2021 at 06:43:53AM +0200, Christoph Anton Mitterer wrote: > On Thu, 2021-07-15 at 21:18 -0700, tony mancill wrote: > > This is certainly a valid point. There is not time to change the > > situation for bullseye aside from filing an RM bug to prevent the > > package from shipping with the release. That would impact transitive > > dependencies of which I believe activemq is the most significant. > > Would it be possible to provide a more current version via backports... > I mean if it's not possible to get it in via some stable-update or so? Yes, this should be possible. I believe we would need to call the package zookeeper35 or zookeeper36. > > As an aside, I took a quick look at the latest upstream activemq > > source > > release (https://activemq.apache.org/activemq-5016002-release) and it > > specifies zookeeper 3.4.14 in its pom.xml (which makes me feel a > > little > > better). > > Isn’t that just telling the minimum version that works with it - not > what they'd consider a safe use from a security PoV? I don't recall there being API issues (although I need to check), but we encountered problems at my $dayjob trying to use ZK 3.5 libraries in applications interacting with ZK 3.4 servers. IIRC, the issue has to do with TTL nodes and was problematic enough that we ended up forking the application to have ZK 3.4 and ZK 3.5 variants. > > We can work on addressing the situation in bookworm. (One idea I > > would > > propose is paring down the package to build just libzookeeper-java, > > because I imagine that many people use the Debian package to run > > their > > ZooKeeper ensembles, although maybe that's not true.) > > Well I for example use the daemon, too, but the software from which I > use it would anyway already require some newer version and doesn't work > with 3.4 anymore. > So for me that wouldn't matter much. It's good to know that there are users of the package. (For my $dayjob use case, ZK deployments are now container-based using the upstream binary distribution.) I will set aside some time to look at what it would take to build a ZK 3.6 package against Debian and we can continue the discussion. Cheers, tony signature.asc Description: PGP signature
Bug#990345: zookeeper: various security issues
On Thu, 2021-07-15 at 21:18 -0700, tony mancill wrote: > The Debian package disables building against Netty via this patch: > https://salsa.debian.org/java-team/zookeeper/-/blob/master/debian/patches/13-disable-netty-connection-factory.patch Ah I see. > This is certainly a valid point. There is not time to change the > situation for bullseye aside from filing an RM bug to prevent the > package from shipping with the release. That would impact transitive > dependencies of which I believe activemq is the most significant. Would it be possible to provide a more current version via backports... I mean if it's not possible to get it in via some st able-update or so? > As an aside, I took a quick look at the latest upstream activemq > source > release (https://activemq.apache.org/activemq-5016002-release) and it > specifies zookeeper 3.4.14 in its pom.xml (which makes me feel a > little > better). Isn’t that just telling the minimum version that works with it - not what they'd consider a safe use from a security PoV? > We can work on addressing the situation in bookworm. (One idea I > would > propose is paring down the package to build just libzookeeper-java, > because I imagine that many people use the Debian package to run > their > ZooKeeper ensembles, although maybe that's not true.) Well I for example use the daemon, too, but the software from which I use it would anyway already require some newer version and doesn't work with 3.4 anymore. So for me that wouldn't matter much. Thanks, Chris.
Bug#990345: zookeeper: various security issues
On Sun, Jun 27, 2021 at 03:12:35PM +0200, Christoph Anton Mitterer wrote: > On Sun, 2021-06-27 at 14:46 +0200, Salvatore Bonaccorso wrote: > > To me this looks like CVEs in other products, but which zookeeper > > uses > > as dependency? Is this correct? > > Indeed, but I couldn't find that the zookeeper package depends on these > while it does contain: > zookeeper-3.4.13/src$ find . -iname "*nett*" > ./java/main/org/apache/zookeeper/server/NettyServerCnxnFactory.java > ./java/main/org/apache/zookeeper/server/NettyServerCnxn.java > ./java/test/org/apache/zookeeper/server/NettyServerCnxnTest.java > ./java/test/org/apache/zookeeper/test/NioNettySuiteTest.java > ./java/test/org/apache/zookeeper/test/NioNettySuiteHammerTest.java > ./java/test/org/apache/zookeeper/test/NioNettySuiteBase.java > > > ... so I figured these might still be affected? The Debian package disables building against Netty via this patch: https://salsa.debian.org/java-team/zookeeper/-/blob/master/debian/patches/13-disable-netty-connection-factory.patch > And apart from that... if they apparently don't support older versions > anymore, we'd like not even notice should these contain any security > issues. This is certainly a valid point. There is not time to change the situation for bullseye aside from filing an RM bug to prevent the package from shipping with the release. That would impact transitive dependencies of which I believe activemq is the most significant. As an aside, I took a quick look at the latest upstream activemq source release (https://activemq.apache.org/activemq-5016002-release) and it specifies zookeeper 3.4.14 in its pom.xml (which makes me feel a little better). We can work on addressing the situation in bookworm. (One idea I would propose is paring down the package to build just libzookeeper-java, because I imagine that many people use the Debian package to run their ZooKeeper ensembles, although maybe that's not true.) Help is always appreciated. Cheers, tony signature.asc Description: PGP signature
Bug#990345: zookeeper: various security issues
Hey. On Sun, 2021-06-27 at 14:46 +0200, Salvatore Bonaccorso wrote: > To me this looks like CVEs in other products, but which zookeeper > uses > as dependency? Is this correct? Indeed, but I couldn't find that the zookeeper package depends on these while it does contain: zookeeper-3.4.13/src$ find . -iname "*nett*" ./java/main/org/apache/zookeeper/server/NettyServerCnxnFactory.java ./java/main/org/apache/zookeeper/server/NettyServerCnxn.java ./java/test/org/apache/zookeeper/server/NettyServerCnxnTest.java ./java/test/org/apache/zookeeper/test/NioNettySuiteTest.java ./java/test/org/apache/zookeeper/test/NioNettySuiteHammerTest.java ./java/test/org/apache/zookeeper/test/NioNettySuiteBase.java ... so I figured these might still be affected? And apart from that... if they apparently don't support older versions anymore, we'd like not even notice should these contain any security issues. Cheers, Chris.
Bug#990345: zookeeper: various security issues
[Disclaimer, not the package maintainer, but quickly checked your report for tracking within the security team] On Sat, Jun 26, 2021 at 01:50:44PM +0200, Christoph Anton Mitterer wrote: > Source: zookeeper > Version: 3.4.13-6 > Severity: grave > Tags: security > Justification: user security hole > X-Debbugs-Cc: Debian Security Team > > > Hi. > > The release notes for > https://zookeeper.apache.org/doc/r3.6.3/releasenotes.html > list various security issues: > CVE-2020-25649 > CVE-2021-21295 > CVE-2021-28165 > CVE-2021-21409 > > It's a bit unclear to me whether 3.4 is affected to, but since 3.5.x > versions seem > to be, I'd guess the issues go back longer and may affect 3.4 as well. > > I would guess that 3.4.x has no upstream support anymore. To me this looks like CVEs in other products, but which zookeeper uses as dependency? Is this correct? CVE-2021-21409 is for instance for netty and fixed in 1:41.48-4 and in DSA 4885-1. CVE-20202-25649 was in jackson-databind. Similar for the other CVEs mentioned in the release notes, and they usually refer to "upgrate X.Y to version [...], dependency check, etc. I have not (yet) checked the respective imapct and if something needs to be changed about those specifically in zookeeper. Regards, Salvatore
Bug#990345: zookeeper: various security issues
Source: zookeeper Version: 3.4.13-6 Severity: grave Tags: security Justification: user security hole X-Debbugs-Cc: Debian Security Team Hi. The release notes for https://zookeeper.apache.org/doc/r3.6.3/releasenotes.html list various security issues: CVE-2020-25649 CVE-2021-21295 CVE-2021-28165 CVE-2021-21409 It's a bit unclear to me whether 3.4 is affected to, but since 3.5.x versions seem to be, I'd guess the issues go back longer and may affect 3.4 as well. I would guess that 3.4.x has no upstream support anymore. Cheers, Chirs.