[security] AWS direct stop can terminate non-Crabbox EC2 instances by raw instance ID

[coygeek]

[security] AWS direct stop can terminate non-Crabbox EC2 instances by raw instance ID

Summary

The direct AWS provider accepts a raw EC2 instance ID in crabbox stop --provider aws --id i-..., resolves it with DescribeInstances, and passes the described instance into the release path without verifying that it is a Crabbox-owned lease. A local operator or automation path that can invoke Crabbox with configured AWS credentials can therefore make Crabbox call TerminateInstances for any describable instance in the configured AWS account/region set, including instances that lack the canonical crabbox=true, created_by=crabbox, provider=aws, lease, and slug tags.

This is in scope under the maintainer-authored SECURITY.md boundary because the policy explicitly calls out destructive provider actions against resources Crabbox cannot strongly identify as its own. It does not depend on hostile multi-tenant isolation; the crossed boundary is Crabbox's provider-resource ownership check before a destructive cloud API call.

Affected Components

• Checked commit: 6dba4afd1c5a4be0a780cf035d1b397e8982d478
• Component: CLI direct AWS provider lifecycle
• Affected files and lines:
  • internal/cli/run.go:2914-3105
  • internal/providers/aws/backend.go:129-149
  • internal/providers/aws/backend.go:200-208
  • internal/providers/aws/backend.go:347-359
  • internal/cli/aws.go:595-615
  • internal/cli/provider_backend.go:680-682

Attack Path

Attacker role:

local operator or local automation with access to configured AWS provider credentials

Prerequisites:

• The local Crabbox configuration selects provider=aws or the caller supplies --provider aws.
• The configured AWS credentials can describe and terminate a target EC2 instance.
• The caller knows or can guess a target EC2 instance ID in the configured AWS region set.
• No internal controller expected-identity flags are supplied; ordinary CLI stop leaves the expected identity empty, so the generic identity validator does not enforce an immutable lease/resource match.

Steps:

1. Choose an EC2 instance ID that is not a Crabbox lease and does not carry Crabbox ownership tags.
2. Run crabbox stop --provider aws --id i-0123456789abcdef0 from a local checkout or automation context using the configured AWS credentials.
3. App.stop resolves the ID with ReleaseOnly: true; because no internal expected identity flags were supplied, ValidateLeaseTargetProviderIdentity returns without checking the resolved target.
4. The AWS backend raw-ID branch calls GetServer for the i-* ID and returns the described server without checking Crabbox ownership tags, lease ID shape, slug, or name.
5. ReleaseLease calls deleteServer, which calls AWSClient.DeleteServer, issuing TerminateInstances for the raw instance ID.

Expected result:

Crabbox terminates an EC2 instance that it cannot strongly identify as a Crabbox-owned lease.

Control/dataflow:

local --id i-* argument
  -> App.stop ResolveRequest{ReleaseOnly: true}
  -> awsLeaseBackend.Resolve raw i-* branch
  -> AWSClient.GetServer without Crabbox tag filter
  -> awsLeaseBackend.ReleaseLease/deleteServer without ownership validation
  -> AWSClient.DeleteServer / EC2 TerminateInstances
  -> non-Crabbox EC2 instance deletion

Impact

This crosses the documented provider-resource safety boundary: Crabbox can perform a destructive provider action against a cloud resource it cannot strongly identify as its own. In an AWS account that mixes Crabbox leases with unrelated EC2 workloads, an operator mistake, malicious local automation, or a compromised local workflow using Crabbox's configured provider route can terminate non-Crabbox instances. The direct AWS inventory cleanup path is narrower because it lists only instances with tag:crabbox=true, while the raw-ID stop path bypasses that inventory filter and has no equivalent release-time ownership gate.

Severity Assessment

CVSS Assessment

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

The attack is local and requires a caller that can use the configured AWS route, so this is not a remote authentication bypass. The impact is high availability loss for the victim EC2 instance because Crabbox reaches a provider termination API without first proving the resource belongs to a Crabbox lease. Confidentiality and integrity are not directly affected by the observed path.

Recommended Remediation

Add a shared AWS ownership validation gate before any destructive AWS direct-provider operation. The gate should reject a server unless it has a canonical Crabbox lease identity: crabbox=true, created_by=crabbox, provider=aws, a valid lease id, a non-empty slug, and preferably the expected Name or provider-key relationship used by created leases. Apply it in both the raw i-* resolve branch when ReleaseOnly is true and in deleteServer as defense in depth. If raw EC2 IDs are intentionally supported for adoption or manual cleanup, require an explicit adoption flow that verifies and writes Crabbox ownership metadata before allowing release.

Validation

Validation method:

source review with local CVSS scoring

Evidence and counterevidence:

• internal/cli/run.go:3067-3093 resolves the user-supplied ID with ReleaseOnly: true, then calls ReleaseLease; ValidateLeaseTargetProviderIdentity is a no-op when no internal expected identity flags were provided.
• internal/providers/aws/backend.go:129-149 has a raw i-* branch that calls GetServer and returns a LeaseTarget without checking crabbox, created_by, provider, lease ID shape, slug, or name.
• internal/cli/aws.go:595-605 implements GetServer with DescribeInstances by instance ID, unlike ListCrabboxServers in internal/cli/aws.go:147-152, which filters on tag:crabbox=true.
• internal/providers/aws/backend.go:200-208 calls deleteServer from ReleaseLease, and internal/providers/aws/backend.go:347-359 calls client.DeleteServer without an AWS ownership check.
• internal/cli/aws.go:610-615 maps DeleteServer to EC2 TerminateInstances.
• internal/cli/provider_labels.go:10-31 shows the canonical tags Crabbox-created direct leases receive, and internal/cli/aws.go:1112-1129 shows that arbitrary EC2 tags are copied into the Server.Labels map returned by GetServer.
• Counterevidence considered: direct AWS cleanup uses ListCrabboxServers, and adjacent providers such as Hetzner and GCP have explicit ownership or canonical-label gates before destructive paths. Those controls do not protect the raw AWS stop path.

Suggested regression coverage or verification:

• internal/providers/aws/backend_test.go: add a test where Resolve(ReleaseOnly: true, ID: "i-foreign") returns a fake instance without Crabbox labels and assert that release is rejected before DeleteServer is called.
• internal/providers/aws/backend_test.go: add a positive test proving canonical Crabbox-tagged AWS leases still release and clean up provider keys.

go test ./internal/providers/aws ./internal/cli
go test ./...

Remaining uncertainty:

No live AWS call was made during discovery; the finding is based on current source flow and local scoring. Verifier can confirm with a fake AWS client regression test without touching real cloud resources.

[clawsweeper]

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

Summary
Keep open: current main and v0.33.0 still have the raw AWS instance-ID stop path, empty expected identity validation can no-op, and release can reach EC2 TerminateInstances without an AWS ownership gate. This is a source-reproducible security boundary issue, not an implemented or duplicate cleanup item.

Reproducibility: yes. Source inspection shows crabbox stop --provider aws --id i-* can resolve a raw EC2 instance through GetServer, skip identity validation when no expected identity is present, and reach TerminateInstances; I did not run live AWS.

Next step
Security-sensitive AWS destructive-action behavior needs maintainer handling before repair; the source path is clear, but raw-ID compatibility and adoption policy should be confirmed.

Security
Needs attention: The issue itself is security-sensitive, and source inspection supports a destructive AWS ownership-boundary concern on current main.

Review details

Best possible solution:

Add AWS-owned-resource validation before raw-ID release and again before DeleteServer, preserving canonical Crabbox-tagged lease release while rejecting or explicitly adopting unowned EC2 IDs.

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

Yes. Source inspection shows crabbox stop --provider aws --id i-* can resolve a raw EC2 instance through GetServer, skip identity validation when no expected identity is present, and reach TerminateInstances; I did not run live AWS.

Is this the best way to solve the issue?

Yes on the remediation direction: fail closed before destructive AWS direct release unless the resolved server has canonical Crabbox ownership evidence. The exact legacy raw-ID or adoption behavior needs maintainer approval because it changes a destructive compatibility path.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• No live AWS reproduction was run; the issue is high-confidence from source flow and should be covered with fake-client regression tests.
• A fix can break users who relied on raw EC2 IDs for unmanaged manual cleanup, so maintainers should confirm the fail-closed or explicit-adoption compatibility path.

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

Label changes

Label changes:

• add P0: The issue describes a credible provider-resource ownership bypass that can drive a destructive cloud API call against a non-Crabbox EC2 instance.
• add impact:security: The affected behavior is the AWS provider security boundary before destructive actions on cloud resources.
• 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 issue describes a credible provider-resource ownership bypass that can drive a destructive cloud API call against a non-Crabbox EC2 instance.
• impact:security: The affected behavior is the AWS provider security boundary before destructive actions on cloud resources.

Evidence reviewed

Security concerns:

• [high] AWS raw-ID stop lacks an ownership gate — internal/providers/aws/backend.go:130
  The direct AWS stop path can resolve an arbitrary raw EC2 instance ID and pass it to the release path without proving the instance is Crabbox-owned before termination.
  Confidence: 0.9

Acceptance criteria:

• go test ./internal/providers/aws ./internal/cli
• go test ./...

What I checked:

• Current raw-ID resolve path: awsLeaseBackend.Resolve special-cases IDs beginning with i-, calls GetServer, derives a lease ID from the instance tags or the raw ID, and returns the target without checking crabbox, created_by, provider, lease, or slug ownership labels. (internal/providers/aws/backend.go:129, 6dba4afd1c5a)
• Empty expected identity bypass: The generic provider identity validator returns nil when no expected identity flags are supplied, which matches the ordinary CLI stop path described in the issue. (internal/cli/provider_backend.go:680, 6dba4afd1c5a)
• Stop reaches release after release-only resolve: App.stop resolves with ReleaseOnly: true, validates the optional expected identity, then calls ReleaseLease; no additional AWS ownership check appears in this core flow. (internal/cli/run.go:3067, 6dba4afd1c5a)
• TerminateInstances sink: AWS release deletes the resolved server by cloud ID, and the AWS client maps that directly to EC2 TerminateInstances. (internal/cli/aws.go:610, 6dba4afd1c5a)
• Security policy boundary: SECURITY.md explicitly lists destructive provider actions against resources Crabbox cannot strongly identify as its own as in scope, and says compatibility-breaking hardening needs product decision and migration planning. (SECURITY.md:44, 6dba4afd1c5a)
• Latest release still has the same raw-ID path: The v0.33.0 tag contains the same AWS raw instance-ID resolve branch and empty expected-identity no-op, so the issue is not already fixed in the latest release. (internal/providers/aws/backend.go:129, 966e99599db4)

Likely related people:

• coygeek: Git blame on the AWS raw-ID resolve, release, delete, EC2 GetServer/DeleteServer, and canonical label helper lines points to Coy Geek's commit ae54e7a. (role: introduced current direct AWS path; confidence: high; commits: ae54e7ae9577; files: internal/providers/aws/backend.go, internal/cli/aws.go, internal/cli/provider_labels.go)
• vincentkoc: The same blame records Vincent Koc as committer for the current direct AWS implementation, and history also shows adjacent AWS orphan audit work. (role: merger and adjacent AWS contributor; confidence: medium; commits: ae54e7ae9577, 50712f2659d9, 0c1d2596496d; files: internal/providers/aws/backend.go, internal/cli/aws.go, worker/src/fleet.ts)
• steipete: Peter Steinberger authored the merged Worker orphan-sweep ownership-proof fix for a related AWS destructive-action boundary, making him relevant for the security/compatibility direction even though this issue is in the CLI direct provider path. (role: adjacent ownership-proof hardening owner; confidence: medium; commits: 4a180939e24d; files: worker/src/fleet.ts, worker/test/fleet.test.ts, docs/features/aws.md)

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.