Bug#1002956: New debdiff
On Sat, 2022-01-29 at 22:53 +0100, Thomas Goirand wrote:
> On 1/29/22 20:31, Salvatore Bonaccorso wrote:
> > Control: tags -1 + moreinfo
> >
> > Hi Thomas,
> >
> > On Sat, Jan 29, 2022 at 07:55:15PM +0100, Thomas Goirand wrote:
> > > My appologies for opening a new bug. I didn't realize #1002956
> > > was still
> > > pending my input. I merged both bugs.
> > >
> > > Please see, attached to this message, the new debdiff, adding the
> > > fix for
> > > CVE-2021-22116 as well.
> >
> > See my comment from
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002956#10 .
> > Isn't
> > the the debian/patches/series missing the listing of
> > CVE-2021-32718_Escape_username_before_displaying_it.patch to
> > actually
> > apply the patch?
> >
> > Regards,
> > Salvatore
>
> Correct, fixed, thanks and sorry for the mistake.
>
+ * Stop moving mv /etc/rabbitmq/rabbitmq.conf /etc/rabbitmq/rabbitmq-env.conf.
This could do with an explanation as to _why_ this move should not be
happening.
+ if ! [ -e /var/lib/rabbitmq/.erlang.cookie ] ; then
+ OLD_UMASK=$(umask)
+ umask 077; openssl rand -base64 -out /var/lib/rabbitmq/.erlang.cookie 42
+ umask ${OLD_UMASK}
+ else
+ # This matches an Erlang generated cookie file: 20 upper case chars
+ if grep -q -E '^[A-Z]{20}$' /var/lib/rabbitmq/.erlang.cookie ; then
+ OLD_UMASK=$(umask)
+ umask 077; openssl rand -base64 -out /var/lib/rabbitmq/.erlang.cookie 42
+ umask ${OLD_UMASK}
+ if [ ""$(ps --no-headers -o comm 1) = "systemd" ] ; then
+ if systemctl is-active --quiet rabbitmq-server.service ; then
+ systemctl restart rabbitmq-server.service
[...]
+Since 3.9.8-3, the rabbitmq-server node will use openssl to generate a
+cryptographically-secure cookie during first installation, mitigating
+this vulnerability.
+
+Servers which installed a prior version, and are upgrading to 3.9.8-3
+or higher, ARE STILL VULNERABLE, as the package will not regenerate
+the secret if it exists already. This is because the secret is
+designed to be shared between nodes in a cluster, and thus
+regenerating it would break existing clusters.
This seems to be inaccurate. The latter block quoted above specifically
*does* regenerate an existing secret if it deems it to be not "good
enough", so far as I can tell?
Regards,
Adam
Reply to: