A compromised workload machine in Juju can read every log file across the entire controller, including all models and entities. This stems from a flaw in the debug log endpoint’s authorization on the API server. Attackers need only the machine agent’s credentials, found in agent.conf, to stream logs at any level—info, debug, or trace—from controllers, units, and charms.
Juju, Canonical’s open-source tool for modeling and deploying applications on clouds or bare metal, relies on controllers to manage models. Models provide isolation for different teams or projects. This vulnerability shatters that: a single hacked workload in one model exposes logs everywhere. The advisory, rated medium severity, points to code in apiserver.go for the authorizer, checked at debuglog.go line 110, then dumping data from line 115 onward.
Technical Breakdown
The endpoint /debuglog streams logs if you’re a machine agent, controller agent, controller admin, or have model read perms. Controller agents and admins face high barriers to lateral movement. Model read is model-scoped. But machine agents run on every unit—including workloads you deploy. Compromise one, grab agent.conf with API keys, and query logs cluster-wide.
Proof-of-concept is straightforward. On the hacked machine:
$ cat /var/lib/juju/agent.conf # Extracts API address, tag, password
$ juju debug-log --model=admin/default --include=debug # Or craft API call to /debuglog
This pulls logs from any entity: controllers, machines, units, applications. Charms—user or store-supplied—dump whatever, uncontrolled. Debug/trace logs often leak secrets: passwords, tokens, API keys, internal configs. Juju 3.x versions before recent patches are hit; check GitHub advisories for your branch.
Why This Matters and What to Do
Juju operators run production workloads: OpenStack clouds, Kubernetes via Charmed K8s, databases, web apps. Multi-model setups mimic multi-tenancy—one team’s sloppy charm shouldn’t dox another’s secrets. Attackers use logs for recon: spot weak units, harvest creds, map the cluster. In finance or crypto ops, this means leaked private keys or trade data.
Real-world context: Juju powers MAAS for metal provisioning, used by telcos and hyperscalers. A 2023 audit found similar agent auth slips in orchestration tools. Skeptically, Juju’s agent model trusts workloads too much—admins expect charm sandboxing, but root on a unit bypasses it. Fair point: debug endpoints are opt-in, but enabled by default in many deploys.
Mitigate now:
- Patch to Juju 3.5+ or whatever fixes auth (
machinemanagerscopes checks). - Disable
debug-logendpoint if unused: controller config tweak. - Segment models strictly; audit charms for log spew.
- Monitor agent.conf access; use Juju’s audit logs.
- Run workloads non-root where possible—though Juju defaults root.
Scan for exploits: compromised units often pivot via SSH or charm hooks. Implications scale with cluster size—100 models? Total exposure. Operators, audit your logs for leaks today. This isn’t hype; it’s a classic auth bypass in a trusted agent flow. Fix it, or risk the fallout.
