Version
main @ e8f77e4 (built from source, no packaged release)
Describe the bug.
BfbRshimCopier::create_unified_preingestion_bfb in
crates/preingestion-manager/src/bfb_rshim_copier.rs writes the BMC root
credentials (fetched from Vault) as plaintext into a bf.cfg blob, which is
appended to a .bfb artifact on local disk at a fixed path:
/forge-boot-artifacts/blobs/internal/aarch64/preingestion_unified_update.bfb
The file is created via tokio::fs::File::create(), which uses the OS
default mode (0o666 minus umask, typically 0644) — no restrictive
permissions (e.g. 0600) are ever set. This means any local user/process
with read access to that path can read the BMC root password in cleartext.
Additionally, the write is gated on the file simply not existing yet
(fs::metadata(...).await.is_err()), so the artifact is written once and
never refreshed. If the BMC credential is later rotated in Vault, this
cached file keeps exposing the stale/old password indefinitely, with no
invalidation logic.
Expected behavior: the artifact should be created with restrictive
permissions (0600) so only the owning process/user can read it, and it
should be invalidated/regenerated whenever the underlying credential
changes, rather than only checked for existence.
This is the same class of issue as #2535 (secret exposure to local
processes via command-line args), but here the secret is persisted to disk
rather than transient in /proc/<pid>/cmdline, and remains stale after
credential rotation.
Minimum reproducible example
1. Trigger `BfbRshimCopier::copy_bfb_to_dpu_rshim` (or directly call
`create_unified_preingestion_bfb`) so the cached artifact is created.
2. As any other local user/process on the same host:
stat /forge-boot-artifacts/blobs/internal/aarch64/preingestion_unified_update.bfb
# note default mode, e.g. 644 — world-readable
3. strings preingestion_unified_update.bfb | grep BMC_PASSWORD
# password appears in cleartext
4. Rotate the BMC credential in Vault, then repeat step 1.
# file is NOT rewritten (fs::metadata check short-circuits), so
# BMC_PASSWORD in the cached file still reflects the OLD password.
Relevant code:
https://github.com/NVIDIA/infra-controller/blob/main/crates/preingestion-manager/src/bfb_rshim_copier.rs#L155-L222
Relevant log output
Other/Misc.
No response
Code of Conduct
Version
main @ e8f77e4 (built from source, no packaged release)
Describe the bug.
BfbRshimCopier::create_unified_preingestion_bfbincrates/preingestion-manager/src/bfb_rshim_copier.rswrites the BMC rootcredentials (fetched from Vault) as plaintext into a
bf.cfgblob, which isappended to a
.bfbartifact on local disk at a fixed path:/forge-boot-artifacts/blobs/internal/aarch64/preingestion_unified_update.bfb
The file is created via
tokio::fs::File::create(), which uses the OSdefault mode (0o666 minus umask, typically 0644) — no restrictive
permissions (e.g. 0600) are ever set. This means any local user/process
with read access to that path can read the BMC root password in cleartext.
Additionally, the write is gated on the file simply not existing yet
(
fs::metadata(...).await.is_err()), so the artifact is written once andnever refreshed. If the BMC credential is later rotated in Vault, this
cached file keeps exposing the stale/old password indefinitely, with no
invalidation logic.
Expected behavior: the artifact should be created with restrictive
permissions (0600) so only the owning process/user can read it, and it
should be invalidated/regenerated whenever the underlying credential
changes, rather than only checked for existence.
This is the same class of issue as #2535 (secret exposure to local
processes via command-line args), but here the secret is persisted to disk
rather than transient in
/proc/<pid>/cmdline, and remains stale aftercredential rotation.
Minimum reproducible example
Relevant log output
Other/Misc.
No response
Code of Conduct