[security] Non-admin broker leases can select AWS security groups, subnets, AMIs, and instance profiles

[coygeek]

[security] Non-admin broker leases can select AWS security groups, subnets, AMIs, and instance profiles

Summary

The brokered AWS lease creation path accepts provider-resource selectors from any authenticated lease request and applies them under the coordinator's AWS principal. A non-admin caller can set awsSGID, awsSubnetID, awsAMI, and awsProfile in POST /v1/leases; leaseConfig() preserves those values, and the AWS provider later uses them for DescribeSecurityGroups, SSH ingress reconciliation, RunInstances, AMI selection, subnet placement, and instance-profile attachment.

This crosses Crabbox's supported coordinator authorization boundary when the broker AWS principal can touch resources beyond the broker-managed runner group and default network. SECURITY.md treats coordinator authentication, ownership, and sharing controls as product boundaries, and lists non-admin escalation plus unsafe provider-resource mutation as in-scope. This is not a hostile-tenant isolation claim or a trusted operator running commands on their own lease; it is a non-admin request causing the privileged broker to operate on caller-selected AWS resources.

Affected Components

• Target commit: 6dba4afd1c5a4be0a780cf035d1b397e8982d478
• Component: Cloudflare Durable Object coordinator AWS lease creation.
• worker/src/fleet.ts:1604-1671 parses the lease request, builds config, and gates snapshot-backed lease sources plus hostID / awsMacHostID behind admin auth, but does not gate awsSGID, awsSubnetID, awsAMI, or awsProfile.
• worker/src/config.ts:281-288 copies awsAMI, awsSnapshot, awsSGID, awsSubnetID, and awsProfile directly from request input into the lease config.
• worker/src/aws.ts:66-75 prefers config.awsSGID over the broker's CRABBOX_AWS_SECURITY_GROUP_ID.
• worker/src/aws.ts:1206-1298 uses the selected security group for DescribeSecurityGroups, stale SSH ingress pruning, and AuthorizeSecurityGroupIngress.
• worker/src/aws.ts:1053-1094 uses config.awsProfile and config.awsSubnetID as IamInstanceProfile.Name and NetworkInterface.1.SubnetId in RunInstances.
• worker/src/aws.ts:1148-1150 uses config.awsAMI before the broker default AMI.
• internal/cli/coordinator.go:799-831 forwards these config values to POST /v1/leases.

Attack Path

Attacker role: authenticated non-admin broker user, including a normal signed user token or shared operator token.

Prerequisites:

• The deployment enables brokered AWS leases.
• The broker AWS principal has permissions broad enough to describe or modify the caller-selected security group, launch in the caller-selected subnet, pass the caller-selected instance profile, or boot the caller-selected AMI.
• The attacker can submit a normal lease creation request.

Steps:

1. Send POST /v1/leases for provider aws with caller-chosen values such as awsSGID, awsSubnetID, awsAMI, awsProfile, and attacker-controlled awsSSHCIDRs.
2. fleet.ts builds a lease config and only rejects non-admin snapshot sources or dedicated-host pins. The AWS selector fields remain in the config.
3. awsConfiguredSecurityGroupID() returns the request's awsSGID, so ensureSecurityGroup() describes that group and reconciles SSH ingress against the request's source CIDRs.
4. createServer() places awsProfile into IamInstanceProfile.Name, places awsSubnetID into NetworkInterface.1.SubnetId, and calls RunInstances with the selected AMI.

Result: if the broker IAM permits those AWS actions, a non-admin Crabbox caller can make the broker add SSH ingress to a security group the operator did not intend Crabbox to manage, launch instances in a caller-selected subnet, attach a caller-selected instance profile, or boot a caller-selected AMI.

Impact

This gives a non-admin broker user partial control over AWS resources and launch identity that are normally governed by the broker operator. In affected deployments, the user can widen SSH reachability on non-managed security groups or launch broker-paid instances with network placement, image, and instance-profile choices that the broker operator did not approve.

The strongest impact is credential and privilege exposure through an attacker-selected instance profile, because the launched machine can receive AWS role credentials intended for a different workload. Security-group and subnet selection can also expose existing network boundaries or place Crabbox instances into unintended VPC segments. The issue is deployment-dependent: least-privilege broker IAM limited to Crabbox-managed resources reduces or prevents exploitation, but the product currently does not fail closed before making the privileged AWS calls.

Severity Assessment

CVSS Assessment

Metric	v3.1	v4.0
Score	7.1 / 10.0	6.1 / 10.0
Severity	High	Medium
Vector	CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N	CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:L/VA:L/SC:L/SI:L/SA:L
Calculator	CVSS v3.1 Calculator	CVSS v4.0 Calculator

The v3.1 vector uses high attack complexity because practical exploitation depends on the broker AWS principal having authority over the selected resources. The v4.0 vector records that deployment precondition as AT:P. The primary risk is confidentiality exposure from attaching an unintended instance profile, with lower integrity and availability effects from unauthorized security-group and placement changes.

Recommended Remediation

Fail closed in createLease() before provider preparation for non-admin AWS resource selectors that can redirect the broker AWS principal:

• Reject non-empty awsSGID from non-admin requests unless it matches an operator-approved broker value.
• Reject non-empty awsSubnetID from non-admin requests unless it matches an operator-approved broker value.
• Reject non-empty awsProfile from non-admin requests unless it is in an operator-maintained allowlist.
• Reject non-empty awsAMI from non-admin requests unless it is selected through Crabbox's promoted image flow or an operator-maintained allowlist.

Add regression coverage in worker/test/fleet.test.ts for non-admin POST /v1/leases requests containing each field. Existing tests already prove analogous admin-only behavior for hostID / awsMacHostID and snapshot-backed lease fields; the new tests should assert the same 403 admin_required behavior for these AWS selectors.

Validation

Validation method: source review of the latest verification checkout at commit 6dba4afd1c5a4be0a780cf035d1b397e8982d478; no live AWS calls were made.

Evidence:

• SECURITY.md says coordinator authentication, ownership, and sharing controls remain product boundaries, and lists non-admin escalation and destructive provider actions against resources Crabbox cannot strongly identify as its own as in scope.
• docs/security.md says brokered AWS leases otherwise scope SSH ingress to the CLI-detected or request-source CIDR, establishing that the broker owns this security posture for brokered leases.
• docs/providers/aws.md documents the AWS selector fields as configuration, and notes that brokered AWS credentials live in the Worker rather than on developer machines. That means a brokered request uses the coordinator's AWS authority, not the user's local AWS authority.
• worker/src/fleet.ts:1654-1671 contains admin checks for nearby high-risk lease sources and host pins, but no equivalent check for awsSGID, awsSubnetID, awsAMI, or awsProfile.
• worker/src/config.ts:281-288 preserves the caller-supplied AWS fields.
• worker/src/aws.ts:66-75, 1206-1298, 1053-1094, and 1148-1150 show those fields reaching AWS API parameters.
• internal/cli/coordinator.go:799-831 confirms the CLI sends these values in broker lease creation requests.

Counterevidence considered:

• These fields are useful operator configuration knobs, and the direct-mode AWS path intentionally lets a trusted local operator choose them. That does not defeat the brokered finding because the brokered path uses the coordinator's AWS credentials for an authenticated non-admin request.
• CRABBOX_AWS_SECURITY_GROUP_ID and managed security group names provide safer defaults when the request omits awsSGID, but awsConfiguredSecurityGroupID() gives request input priority.
• Least-privilege broker IAM can limit exploitability. This is reflected in the severity and prerequisites, but Crabbox still accepts and attempts privileged provider operations for non-admin caller-selected resources.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 25, 2026, 9:56 PM ET / 01:56 UTC.

Summary
Keep open: current main and latest release still preserve non-admin AWS selector fields and pass them to AWS API calls under broker authority, and no merged or viable open PR appears to own the AWS-specific fix.

Reproducibility: yes. Source inspection shows a crafted non-admin POST /v1/leases can carry AWS selector fields through leaseConfig into AWS provider calls; no live AWS exploit was run.

Next step
This is a security-sensitive authorization and compatibility decision, so maintainers should choose the broker AWS policy before an implementation PR is queued.

Security
Needs attention: Source inspection supports a security-sensitive coordinator authorization gap in brokered AWS lease creation.

Review details

Best possible solution:

Land a security-reviewed coordinator policy that rejects non-admin AWS selector overrides unless they match broker-approved defaults, promoted images, or an explicit operator allowlist, with regression tests and broker docs updated.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection shows a crafted non-admin POST /v1/leases can carry AWS selector fields through leaseConfig into AWS provider calls; no live AWS exploit was run.

Is this the best way to solve the issue?

Yes on the fix boundary, unclear on the exact compatibility policy. The narrow maintainable direction is a coordinator-side authorization gate before provider calls, while maintainers choose admin-only, default-match, or allowlist semantics.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Exploitability and severity depend on how broadly a deployment scopes the broker AWS IAM principal.
• Existing docs expose these selector fields as useful AWS configuration, so tightening broker behavior needs an explicit compatibility and operator-policy decision.

Codex review notes: model internal, reasoning high; reviewed against 6dba4afd1c5a.

Label changes

Label changes:

• add P0: The report describes a non-admin broker user steering privileged AWS identity, network, image, and security-group choices in affected deployments.
• add impact:security: The issue concerns coordinator authorization and cloud provider resource boundaries for brokered AWS leases.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.
• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P0: The report describes a non-admin broker user steering privileged AWS identity, network, image, and security-group choices in affected deployments.
• impact:security: The issue concerns coordinator authorization and cloud provider resource boundaries for brokered AWS leases.

Evidence reviewed

Security concerns:

• [high] Non-admin AWS selectors reach privileged broker calls — worker/src/fleet.ts:1654
  Non-admin lease requests can supply AWS security group, subnet, AMI, and instance profile selectors that are later used under the coordinator's AWS credentials.
  Confidence: 0.88

Acceptance criteria:

• npm test --prefix worker -- fleet.test.ts aws.test.ts
• npm run check --prefix worker
• npm run lint --prefix worker

What I checked:

• Repository policy read: AGENTS.md was read fully; its provider-boundary guidance applies because this issue concerns AWS-specific authorization and resource selection behind provider adapters. (AGENTS.md:1, 6dba4afd1c5a)
• Security boundary: SECURITY.md treats coordinator authentication, ownership, and sharing controls as product boundaries and lists non-admin escalation plus unsafe provider-resource mutation as in scope. (SECURITY.md:22, 6dba4afd1c5a)
• Brokered AWS authority: AWS docs say brokered AWS credentials live in the Worker, so broker lease selector fields are consumed under coordinator-side cloud credentials rather than the caller's local AWS credentials. (docs/providers/aws.md:119, 6dba4afd1c5a)
• Lease-create gap on current main: createLease rejects non-admin native lease sources and provider host pins but has no equivalent guard for awsSGID, awsSubnetID, awsAMI, or awsProfile before provider preparation. (worker/src/fleet.ts:1654, 6dba4afd1c5a)
• Request fields preserved: leaseConfig copies awsAMI, awsSGID, awsSubnetID, and awsProfile directly from LeaseRequest input into LeaseConfig. (worker/src/config.ts:281, 6dba4afd1c5a)
• AWS provider sinks: AWS provider code gives request awsSGID priority over the environment security group, uses awsProfile and awsSubnetID in RunInstances parameters, and resolves awsAMI before the default image path. (worker/src/aws.ts:66, 6dba4afd1c5a)

Likely related people:

• coygeek: Available local blame for createLease, leaseConfig, and AWS sink lines resolves to ae54e7a, and GitHub history shows related fail-closed Worker input validation work. (role: current-line provenance and recent worker security contributor; confidence: medium; commits: ae54e7ae9577, e7be0273d063; files: worker/src/fleet.ts, worker/src/config.ts, worker/src/aws.ts)
• steipete: Recent path history shows AWS region validation, workspace SSH ingress isolation, and the merged dedicated-host authorization fix that added the adjacent host-pinning admin gate. (role: recent AWS/coordinator security area contributor; confidence: medium; commits: edc893117b73, f3bafdb4ef18, ea2a9f538518; files: worker/src/aws.ts, worker/src/fleet.ts, worker/test/fleet.test.ts)
• vincentkoc: Recent path history shows AWS security-group behavior, owned-image metadata, and Worker cleanup/security hardening in the affected files. (role: recent AWS and Worker provider contributor; confidence: medium; commits: 583f473aa01b, b9163e9d971f; files: worker/src/aws.ts, worker/src/fleet.ts, worker/test/fleet.test.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.