fix: acra-backup export writes wrong data, zeroizes key before write, leaks key to logs#737
Open
zenmpi wants to merge 1 commit intocossacklabs:masterfrom
Open
fix: acra-backup export writes wrong data, zeroizes key before write, leaks key to logs#737zenmpi wants to merge 1 commit intocossacklabs:masterfrom
zenmpi wants to merge 1 commit intocossacklabs:masterfrom
Conversation
… leaks key to logs Three bugs in acra-backup --action=export: 1. WriteFile used backup.Keys (raw master key) instead of backup.Data (encrypted bundle), making export/import incompatible (CWE-312) 2. ZeroizeSymmetricKey was called before WriteFile, so the file received 32 null bytes (Go slices share underlying array) 3. Master key was logged via log.Infof, exposing it to log aggregation systems (CWE-532) Fix: write backup.Data, move zeroize after write+encode, output key via fmt.Fprintf(os.Stderr) formatted as export BACKUP_MASTER_KEY=<b64> to match what import expects from the env var.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Three critical security vulnerabilities in
acra-backup --action=export(cmd/acra-backup/acra-backup.golines 149-161).Vuln 1: Raw master key written to backup file (CWE-312: Cleartext Storage of Sensitive Information)
os.WriteFile(file, backup.Keys, ...)writes the raw master key (32 bytes) to the backup file instead ofbackup.Data(the encrypted key bundle).The
Export()function (keystore/filesystem/filesystem_backup.go:331) returns:But the import path (
acra-backup.go:139-144) expects the file to containData:Export writes
Keysto file, import reads the file intoData— the raw master key is stored on disk in cleartext and the export/import cycle is completely broken.Vuln 2: Premature key zeroization — backup file contains null bytes
utils.ZeroizeSymmetricKey(backup.Keys)on line 156 zeros the slice in-place beforeos.WriteFileon line 157. Since Go slices share the underlying array,WriteFilereceives a buffer filled with 32 null bytes. The backup file is silently corrupted with no error indication.Vuln 3: Master key leaked to log aggregation (CWE-532: Insertion of Sensitive Information into Log File)
log.Infof("Backup master key: %s\n Backup saved to file: %s", base64MasterKey, file)sends the full base64-encoded master key through the logrus logging framework, which may forward to syslog, ELK, CloudWatch, Datadog, Splunk, or container log drivers (Docker, Kubernetes). The key persists in log storage indefinitely with no rotation mechanism.PoC test output
Impact
Severity: Critical
The backup master key protects the encrypted key bundle (
backup.Data), which contains:These private keys decrypt all data protected by Acra in the database.
Attack scenario (Vuln 3): Any actor with read access to logs (SOC analyst, log aggregation service, compromised ELK/Splunk instance, shared CI/CD output) can recover the master key in base64 during an
acra-backup exportoperation. With the master key, the attacker decrypts the backup bundle and gains access to all client encryption keys — full compromise of the cryptographic envelope.Data loss scenario (Vuln 1 + 2): The export/import cycle is completely broken. The file written by export contains either 32 null bytes (due to premature zeroization) or the raw master key (wrong field), neither of which is valid input for import. Users who rely on
acra-backupfor disaster recovery have no functional backup.The replacement tool
acra-keys exportdoes not have these issues — it writesDataandKeysto separate files with 0600 permissions and does not log key material.Fix
Five changes in the
case actionExport:block:os.WriteFile(file, backup.Keys, ...)os.WriteFile(file, backup.Data, ...)— write encrypted bundleZeroizeSymmetricKeybeforeWriteFileWriteFilefirst, then encode, thenZeroizeSymmetricKeylog.Infof("Backup master key: %s", ...)fmt.Fprintf(os.Stderr, "export %s=%s", ...)— bypass logging frameworkbase64MasterKeyasstringencodedKeyas[]byte— mutable, can be zeroedutils.ZeroizeBytes(encodedKey)afterFprintf— full zeroize chainThe output format
export BACKUP_MASTER_KEY=<base64>matches whatactionImportexpects viaos.Getenv(BackupMasterKeyVarName)(line 124).fmtis already imported (line 22). No new dependencies.Diff
Verification
github.com/cossacklabs/themis)acra-backupbinary successfully —go build ./cmd/acra-backup/KeysBackupwithData(encrypted bundle) +Keys(master key)WriteFilewritesbackup.Datato file — verified file is not all zerosbackup.Keysinto[]byte, thenZeroizeSymmetricKey— verified all bytes are 0Fprintfto stderr, thenZeroizeBytes(encodedKey)— verified all bytes are 0Data, decodes base64 env var intoKeys, callsbackuper.ImportTest plan
go build ./cmd/acra-backup/compiles without errorsbackup.Data) to file, not raw master keyexport BACKUP_MASTER_KEY=<b64>formatbackup.Keys(raw key bytes) zeroed after base64 encodeencodedKey(base64[]byte) zeroed after stderr write