Files
seaweedfs/weed/s3api/s3_validation_utils_require_test.go
Chris Lu e1d5e3899f fix(s3): add HMAC-SHA256 key commitment to SSE-S3 and SSE-KMS (#8879)
* fix(s3): add HMAC-SHA256 key commitment to SSE encryption modes

* fix(s3): validate SSE-S3 IV length before cipher.NewCTR

CreateSSES3DecryptedReader took the IV directly from object metadata
and passed it to cipher.NewCTR. The standard library panics when the
IV length differs from the block size, so a tampered metadata field
turned what should be a decryption error into a crash. Validate via
the existing ValidateIV helper first.

Addresses coderabbit review on PR #8879.

* fix(s3): centralize SSE-KMS key commitment in createSSEKMSKey

KeyCommitment used to be set explicitly in only one of the four
encryption entry points; the multipart-aware variants and the bucket-
bound CreateSSEKMSEncryptedReaderForBucket left it empty, so writes
through those paths landed with metadata that VerifyKeyCommitment
treats as legacy and accepts unconditionally — exactly the downgrade
gap the gemini review flagged.

Move the HMAC computation into createSSEKMSKey so every helper-driven
path picks it up automatically, and add the same call to the bucket-
scoped path that builds its own struct literal.

Addresses gemini review on PR #8879.

* fix(s3): store base IV (not derived IV) for offset-aware SSE-KMS chunks

CreateSSEKMSEncryptedReaderWithBaseIVAndOffset used to store the
already-offset-derived IV plus the chunk offset in metadata. The
decrypt path then applied calculateIVWithOffset a second time to
that stored IV, producing the wrong CTR keystream and a decryption
mismatch. Centralizing the key commitment made the bug visible as a
commitment failure, but the underlying issue predates that change.

Pass the base IV through to createSSEKMSKey so sseKey.IV is the
unmodified base on disk; the decrypt path's offset application then
recovers the correct chunk-level IV. The HMAC commitment binds the
base IV — same value the verify call at decrypt time hashes — so the
new commitment path stays consistent.

Addresses gemini security-high review on PR #8879.

* fix(s3): opt-in strict-commitment mode to close the downgrade vector

WEED_S3_REQUIRE_KEY_COMMITMENT=true flips VerifyKeyCommitment from
accept-when-missing (the AWS-compatible default needed for objects
written before commitments shipped) to reject-when-missing. With
the env var set, an attacker who strips the commitment field from
object metadata can no longer bypass integrity verification — every
object must carry a commitment that hashes to the right value.

Default stays false so existing legacy objects keep decrypting; the
warning the gemini review raised about the silent-downgrade vector
is closed for operators who explicitly opt in once their bucket is
fully migrated. SetRequireKeyCommitment exposes a runtime seam for
tests and future config-reload paths.

Addresses the security-medium review on PR #8879.

* test(s3): fix mislabelled IV literal in strict-commitment test

The "strict-mode-iv-16" literal was actually 17 bytes — the trailing
"16" was meant as a comment but counted as content. The IV is fed
into HMAC, not AES, so the length didn't matter for behaviour, but
the discrepancy was confusing. Tighten to a real 16-byte literal and
explain the choice in a comment.

Addresses coderabbit minor review on PR #8879.

* fix(s3): store KMS-resolved KeyID in SSE-KMS metadata, not the request

CreateSSEKMSEncryptedReaderForBucket built its SSEKMSKey with the
caller-supplied keyID, but CreateSSEKMSDecryptedReader later compares
decryptResp.KeyID against sseKey.KeyID. A request that used an alias
would resolve to a different ARN in the response; storing the request
form would then trip the mismatch check at decrypt time and surface
as a "KMS key ID mismatch" error against the operator's own object.
The helper-driven encryption paths already do the right thing via
createSSEKMSKey; this is the bucket-bound path catching up.

Addresses coderabbit review on PR #8879.

* test(s3): cover key commitment rejection paths under tampering

Adds the negative-path tests coderabbit flagged as missing: a
tampered key, IV, algorithm, or commitment field must fail
VerifyKeyCommitment, otherwise a regression in the rejection logic
could land silently. The HMAC binds all three inputs plus the
commitment itself, so any single mutation is enough.

Addresses coderabbit nitpick on PR #8879.
2026-05-04 19:14:41 -07:00

103 lines
3.9 KiB
Go

package s3api
import "testing"
func TestVerifyKeyCommitment_DefaultAcceptsMissing(t *testing.T) {
// Default behaviour mirrors AWS: a missing commitment field is treated
// as a legacy object and accepted. This is the cushion that lets
// operators upgrade without breaking pre-commitment uploads.
prev := requireKeyCommitment.Load()
t.Cleanup(func() { requireKeyCommitment.Store(prev) })
requireKeyCommitment.Store(false)
if err := VerifyKeyCommitment([]byte("k"), []byte("iv"), "AES256", nil); err != nil {
t.Fatalf("default path should accept missing commitment, got: %v", err)
}
}
func TestVerifyKeyCommitment_StrictRejectsMissing(t *testing.T) {
// Strict mode: any object whose metadata lacks the commitment field is
// rejected. Closes the silent-downgrade vector — an attacker who can
// strip the commitment from metadata can no longer bypass verification.
prev := requireKeyCommitment.Load()
t.Cleanup(func() { requireKeyCommitment.Store(prev) })
requireKeyCommitment.Store(true)
err := VerifyKeyCommitment([]byte("k"), []byte("iv"), "AES256", nil)
if err == nil {
t.Fatal("strict mode should reject missing commitment; got nil error")
}
}
func TestVerifyKeyCommitment_StrictAcceptsValidCommitment(t *testing.T) {
// Strict mode does not change the verification outcome for objects that
// do carry a commitment — the only behavioural delta is the missing
// case.
prev := requireKeyCommitment.Load()
t.Cleanup(func() { requireKeyCommitment.Store(prev) })
requireKeyCommitment.Store(true)
key := []byte("strict-mode-test-key")
// IV here is just an opaque input to the HMAC commitment; the test
// doesn't pass it into AES-CTR so it doesn't have to be the AES block
// size. The 16 bytes match the AES block size to keep the literal
// realistic.
iv := []byte("strict-mode-iv16")
commit := ComputeKeyCommitment(key, iv, "AES256")
if err := VerifyKeyCommitment(key, iv, "AES256", commit); err != nil {
t.Fatalf("strict mode should accept valid commitment, got: %v", err)
}
}
func TestVerifyKeyCommitment_RejectsTamperedKey(t *testing.T) {
// Real attack shape: an attacker who can mutate object metadata cannot
// craft a valid commitment without the original key. The verify path
// must catch it whether they tamper with the key, the IV, or the
// algorithm — all three are bound by the HMAC.
prev := requireKeyCommitment.Load()
t.Cleanup(func() { requireKeyCommitment.Store(prev) })
requireKeyCommitment.Store(false)
originalKey := []byte("legit-key-for-commitment")
iv := []byte("commitment-iv-16")
algo := "AES256"
commit := ComputeKeyCommitment(originalKey, iv, algo)
t.Run("tampered key", func(t *testing.T) {
if err := VerifyKeyCommitment([]byte("attacker-substituted-key"), iv, algo, commit); err == nil {
t.Fatal("verify must reject when the key changed but commitment did not")
}
})
t.Run("tampered IV", func(t *testing.T) {
if err := VerifyKeyCommitment(originalKey, []byte("attacker-iv-16!!"), algo, commit); err == nil {
t.Fatal("verify must reject when the IV changed but commitment did not")
}
})
t.Run("tampered algorithm", func(t *testing.T) {
if err := VerifyKeyCommitment(originalKey, iv, "AES128", commit); err == nil {
t.Fatal("verify must reject when the algorithm changed but commitment did not")
}
})
t.Run("tampered commitment", func(t *testing.T) {
bad := append([]byte{}, commit...)
bad[0] ^= 0x01
if err := VerifyKeyCommitment(originalKey, iv, algo, bad); err == nil {
t.Fatal("verify must reject when the commitment itself was flipped")
}
})
}
func TestSetRequireKeyCommitment(t *testing.T) {
prev := requireKeyCommitment.Load()
t.Cleanup(func() { requireKeyCommitment.Store(prev) })
SetRequireKeyCommitment(true)
if !requireKeyCommitment.Load() {
t.Fatal("SetRequireKeyCommitment(true) did not propagate to the atomic")
}
SetRequireKeyCommitment(false)
if requireKeyCommitment.Load() {
t.Fatal("SetRequireKeyCommitment(false) did not propagate to the atomic")
}
}