[BUG] AWS SSM session TokenValue logged at Info level [backplane-cli] #973

[samanthajayasinghe]

After StartSession returns, the code emits the SSM StreamUrl and TokenValue with logger.Infof. logrus defaults to Info, so every invocation of ocm-backplane cloud ssm-session prints the websocket auth token to stdout/terminal scrollback and any log collector attached to the SRE workstation. The token is sufficient on its own to attach to the live SSM session against the customer EC2 instance.

Evidence

logger.Infof("SessionId: %v", *result.SessionId)
logger.Infof("StreamUrl: %v", *result.StreamUrl)
logger.Infof("TokenValue: %v", *result.TokenValue)
cmd/ocm-backplane/cloud/ssm.go:253-255

Remediation
Drop the TokenValue (and StreamUrl) log lines entirely, or downgrade to Trace and redact the token. The session JSON is already passed privately to session-manager-plugin via argv.

Attack Pattern
Local user or log-aggregation reader on the SRE host → hijack the active AWS SSM session to the managed-cluster EC2 node.

Details
Severity: high (CVSS 6.5 — CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N)
CWEs: CWE-532; CWE-312
Category: OWASP K8s K03 Secrets Management / ASVS V7.1 Log Content
Repository: https://github.com/openshift/backplane-cli
Commit: 512767c
Location: cmd/ocm-backplane/cloud/ssm.go

Source
This finding was identified by Project Glasswing: HCMSEC-3528: Prototype AI scanning/testing/fixes across Hybrid Platforms to support the AI SDLC
New

Finding path: backplane/backplane-cli

As this content is AI generated, it should be reviewed with scrutiny for accuracy.

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 5:32 AM UTC · Completed 5:35 AM UTC
Commit: ae64d7c · View workflow run →

[fullsend-ai-triage]

Triage Summary

Severity: High (Security) · CWE-532, CWE-312

Problem

The SSM session start flow in cmd/ocm-backplane/cloud/ssm.go (lines 252–254) logs the TokenValue and StreamUrl at Info level via logger.Infof. Since logrus defaults to Info, every invocation of ocm-backplane cloud ssm-session prints the SSM websocket auth token to stdout. This token is sufficient to hijack the live SSM session to a customer EC2 instance.

Source code inspection confirms the three log lines exist at the reported location and that the session data is already passed to session-manager-plugin via argv, making these log lines unnecessary.

Root Cause

Debug-level logging statements were left at Info level, causing sensitive session credentials to be emitted on every run.

Recommended Fix

Remove the logger.Infof lines for TokenValue (line 254) and StreamUrl (line 253). The SessionId line (252) can optionally be kept at Debug/Trace level. No functional behavior depends on these log lines — the session JSON is already passed privately to session-manager-plugin.

Proposed Test Case

Test: SSM session start should not log sensitive credentials

1. Mock the SSM client to return known SessionId, StreamUrl, and TokenValue
2. Invoke the session-start function
3. Capture all log output
4. Assert TokenValue does NOT appear at Info level or below
5. Assert StreamUrl does NOT appear at Info level or below
6. Edge case: even at Debug/Trace level, TokenValue should be redacted

---

Labels: This is a confirmed security issue involving sensitive credential exposure in logs. The 'bug' label is already applied and appropriate.

[samanthajayasinghe]

/fs-code

[fullsend-ai-coder]

🤖 Finished Code · ✅ Success · Started 5:38 AM UTC · Completed 5:54 AM UTC
Commit: ae64d7c · View workflow run →

[samanthajayasinghe]

/fs-retro