Listen to this Post
How the CVE Works
The vulnerability occurs when the Contrast initializer is configured with `CONTRAST_LOG_LEVEL` set to `info` or debug, causing workload secrets to be logged to `stderr` and stored in Kubernetes logs. Since `info` is the default log level, any deployment not explicitly setting `CONTRAST_LOG_LEVEL=warn` is affected. Kubernetes users with `get` or `list` permissions on `pods/logs` or external entities with log storage access (e.g., cloud providers) can retrieve these secrets. This bypasses intended access controls, exposing sensitive data to unauthorized parties.
DailyCVE Form
Platform: Edgeless Systems Contrast
Version: <=1.7
Vulnerability: Information Disclosure
Severity: Critical
Date: 2023-XX-XX
Prediction: Patch by Q1 2024
What Undercode Say:
Exploit Analysis:
- Attackers with pod log access can extract secrets:
kubectl logs <initializer-pod> | grep "workload secret"
- Cloud logging services (e.g., AWS CloudWatch) may retain exposed secrets.
Protection Commands:
1. Mitigate by enforcing log level:
export CONTRAST_LOG_LEVEL=warn contrast generate --force
2. Revoke unnecessary pod log permissions:
kubectl create clusterrole no-pod-logs --verb=get --resource=pods
Kubernetes Audit Rule:
apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: Metadata resources: - group: "" resources: ["pods/logs"]
Detection Script (Python):
import subprocess
logs = subprocess.check_output(["kubectl", "logs", "initializer-pod"])
if b"workload secret" in logs:
print("VULNERABLE: Secrets leaked in logs!")
Post-Patch Verification:
kubectl exec initializer-pod -- env | grep CONTRAST_LOG_LEVEL Expected: CONTRAST_LOG_LEVEL=warn
Network Policy to Restrict Log Access:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: restrict-log-access
spec:
podSelector: {}
ingress:
- from: []
Secret Rotation Post-Exploit:
contrast coordinator rotate-secrets --namespace=default
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
