Bug#990345: zookeeper: various security issues

2022-01-28 Thread Christoph Anton Mitterer
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

2021-07-17 Thread tony mancill
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

2021-07-15 Thread Christoph Anton Mitterer
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

2021-07-15 Thread tony mancill
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

2021-06-27 Thread Christoph Anton Mitterer
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

2021-06-27 Thread Salvatore Bonaccorso
[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

2021-06-26 Thread Christoph Anton Mitterer
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.