mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-05-14 05:41:29 +00:00
* 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.
103 lines
3.9 KiB
Go
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")
|
|
}
|
|
}
|