Bug#1002956: New debdiff
On Sat, 06 Aug 2022 19:09:05 +0100 "Adam D. Barratt"
<adam@adam-barratt.org.uk> wrote:
> + * 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.
I believe this is https://bugs.debian.org/943699
> + 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?
The README.debian changes are out of date with the code, yes. The
warnings in README.debian, I believe, date from when that
documentation was a compromise solution, rather than fixing existing
weak magic cookies. Since the code now does address those, the README
should be updated accordingly. The changelog might also merit a
warning that this may break clustered installs which share a weak
magic cookie, similar to the note in the initial mail of
https://bugs.debian.org/1004513
- Alex
Reply to: