The localLoginHandlers struct in the Juju API server maintains an in-memory map to store discharge tokens following successful local authentication. This map is accessed concurrently from multiple HTTP handler goroutines without any synchronization primitive protecting it. The absence of a mutex or equivalent mechanism means that concurrent reads, writes, and deletes on the map can trigger Go runtime panics and may allow a discharge token to be consumed more than …
If a user has login permission to a controller and knows the controller model UUID, they can call the CloudSpec method on the Controller facade and get cloud credentials used to bootstrap the controller. The CloudSpec API is called by workers running in the controller to maintain connection to the cloud - this aspect is not the issue. The API is also called by the CLI when killing (force destroying …
It is possible that a compromised workload machine under a Juju controller can read any log file for any entity in any model at any level. There is a debug log endpoint in the API server that allows streaming of logs off of the controller. To access this endpoint you must be authentication and either be a machine agent, controller agent, controller admin or have model read permission. The problematic …
Any authenticated user, machine or controller under a Juju controller can modify the resources of an application within the entire controller. This one is very straightforward to just read in the code:
Any 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-L324
An authorization bypass vulnerability in the Vault secrets back-end implementation of Juju versions 3.1.6 through 3.6.18 allows an authenticated unit agent to perform unauthorized updates to secret revisions. With sufficient information, an attacker can poison any existing secret revision within the scope of that Vault secret back-end.
Grantee is able to update secret content using the secret-set tool due to broad Kubernetes access policy. Implications are that it is possible, knowing a Kubernetes secret identifier (e.g. name), to patch without affecting the secret, revealing the value, or, patching while affecting the secrets value.
A race condition in the secrets management subsystem of Juju versions 3.0.0 through 3.6.18 allows an authenticated unit agent to claim ownership of a newly initialized secret. Between generating a Juju Secret ID and creating the secret's first revision, an attacker authenticated as another unit agent can claim ownership of a known secret. This leads to the attacking unit being able to read the content of the initial secret revision.
Predictable secret ID and lack of secret origin API enable confused deputy attacks on Juju workloads.
Cross-model Relation authorization is broken and has a potential security vulnerability. If the controller does not have the root key to verify the macaroon (or if the macaroon has expired), an unvalidated and therefore untrusted macaroon is used to extract declared caveats. Facts from these caveats are then blindly used to mint a new macaroon that becomes valid.