GHSA-gvrj-cjch-728p: Juju has Improper TLS Client/Server authentication and certificate verification on Database Cluster
ImpactAny Juju controller since 3.2.0.An attacker with only route-ability to the target juju controller Dqlite cluster endpoint
may join the Dqlite cluster, read and modify all information, including escalating privileges,
open firewall ports etc.This is due to not checking the client certificate, additionally, the client does not
check the server's certificate (MITM attack possible), so anything goes.https://github.com/juju/juju/blob/001318f51ac456602aef20b123684f1eeeae9a77/internal/database/node.go#L312-L324PoCUsing the tool referenced below.Bootstrap a controller and show the users:Join the cluster with the first cluster member:Join the cluster with another cluster member and give the admin a new name:The admin won't like this new name:PatchesJuju versions 3.6.20 and 4.0.5 are patched to fix this issue.WorkaroundsThe strongest protection is to apply the security updates. The following mitigations have also been explored. If security updates cannot be applied, you should only apply the following steps as a last resort and restore the original configuration file once updates are applied. Please note that modifying configuration files may stop future unattended upgrades from completing successfully, until these are reverted to the original content.Option 1: Disable the HA (High Availability) controller. If your environment does not strictly require HA, reducing the cluster to a single controller removes the need for DQlite replication. Moreover, the port that replicates the vulnerability should be blocked, namely 17666.
Option 2: Restrict what IPs can communicate with port 17666, by implementing firewall rules to block all ingress traffic to this port. Only Juju controller IPs should be able to connect to this port.To restrict access to the DQlite port to just the set of controller IPs, here's an example using ufw for a machine controller. This needs to be run on each controller. If the controller nodes change configuration, the rules will need to be updated accordingly.
You will need to enable access to the controller API port 17070 in accordance with your requirements for allowing clients to connect to the Juju controllers.For Kubernetes controllers, HA is not supported. We recommend blocking access to port 17666. One way is to apply a network policy:Referenceshttps://github.com/juju/juju/blob/001318f51ac456602aef20b123684f1eeeae9a77/internal/database/node.go#L312-L324PoC ToolBased on the go-dqlite demo app.MitigationThe strongest protection is to apply the security updates. The following mitigations have also been explored. If security updates cannot be applied, you should only apply the following steps as a last resort and restore the original configuration file once updates are applied. Please note that modifying configuration files may stop future unattended upgrades from completing successfully, until these are reverted to the original content.Option 1: Disable the HA (High Availability) controller. If your environment does not strictly require HA, reducing the cluster to a single controller removes the need for DQlite replication. Moreover, the port that replicates the vulnerability should be blocked, namely 17666.
Option 2: Restrict what IPs can communicate with port 17666, by implementing firewall rules to block all ingress traffic to this port. Only Juju controller IPs should be able to connect to this port.To restrict access to the DQlite port to just the set of controller IPs, here's an example using ufw for a machine controller. This needs to be run on each controller. If the controller nodes change configuration, the rules will need to be updated accordingly.
You will need to enable access to the controller API port 17070 in accordance with your requirements for allowing clients to connect to the Juju controllers.For Kubernetes controllers, HA is not supported. We recommend blocking access to port 17666. One way is to apply a network policy:
CVSS v3.1: 10