NVIDIA DGX Spark provisioning flaw enables SSH host impersonation

NVIDIA DGX OS contains a vulnerability in the factory provisioning process, where the cloning of a base image causes identical SSH host keys to be deployed across multiple systems. The sharing of cryptographic identifiers across all similarly provisioned systems enables host impersonation or attacker-in-the-middle attacks. A successful exploit of this vulnerability might lead to code execution, data tampering, escalation of privileges, information disclosure, and denial of service.

• NVIDIA DGX Spark on NVIDIA DGX OS: NVIDIA identifies all versions prior to OTA0 as affected. • OTA0 is the updated version identified by NVIDIA for this issue. • The available evidence does not confirm the status of other products, platforms, or release branches.

The flaw is in the NVIDIA DGX OS factory provisioning process. When a base image containing system identifiers is cloned for deployment to multiple machines, those machines can receive the same SSH host keys and machine-id instead of unique values. This is a shared cryptographic identifier weakness consistent with CWE-321. When systems or administrators rely on SSH host keys to identify a server, duplicate keys can enable host impersonation or attacker-in-the-middle activity; this consequence is stated by the advisory, while the specific packet sequence is not disclosed. The record characterizes the issue as network-reachable, requiring no prior privileges or user interaction, but requiring high attack complexity. The precise implementation detail that causes the keys to be copied during factory provisioning is not publicly described.

The record characterizes the vulnerability as reachable over the network, requiring no prior authentication and no user interaction; attack complexity is high. The described attack classes are host impersonation and attacker-in-the-middle activity against systems provisioned in the same way. The available evidence does not define the attacker's exact network position, an exploitation sequence, a payload, or the conditions needed to bypass SSH host-key checks in a particular environment. The supplied record does not identify a public exploit and does not establish that exploitation has occurred. The absence of a listed public exploit does not prove that exploitation is impossible or has not occurred outside the available evidence.

The flaw breaks the assumption that each server has a unique SSH host identity. An attacker may use duplicate identifiers to impersonate a host or perform attacker-in-the-middle activity against relevant connections, potentially affecting system confidentiality, integrity, and availability. The advisory lists possible outcomes including code execution, data tampering, privilege escalation, information disclosure, and denial of service, but does not describe the exact path to each outcome. The record does not indicate a change in security scope, although the practical effect can extend across multiple systems created from the same image. Actual impact depends on the connections, services, and privileges exposed by those systems.

• Systems in the same fleet may no longer have unique SSH identities, reducing confidence in connection and authentication decisions between hosts. • If a connection is impersonated or intercepted, possible consequences include information disclosure, data tampering, privilege escalation, code execution, and denial of service, depending on the services and privileges exposed through that connection. • Exposure is concentrated in systems provisioned from a cloned base image; the available evidence does not establish that every NVIDIA DGX Spark deployment is affected. • Response requires image inventory, identifier checks on deployed systems, and updating or regenerating identifiers before affected SSH relationships are trusted again. • The available evidence does not identify a breach, victim, or campaign.

1. Update NVIDIA DGX Spark to OTA0, the updated version identified by NVIDIA for this issue.

2. For new image creation, capture the golden image before the system's initial boot, before SSH host keys and machine-id are generated.

3. For deployed systems, check the SSH host-key files and /etc/machine-id for duplication with the golden image or another system.

4. If duplicates are found, regenerate the identifiers after booting from the SSD. NVIDIA provides these commands:

   sudo truncate -s 0 /etc/machine-id
   sudo systemd-machine-id-setup
   

   rm /etc/ssh/ssh_host_*
   ssh-keygen -A
   

5. Validate that the regenerated identifiers differ from the original golden image and meet the requirement for unique identifiers on each system.

6. NVIDIA states that the DGX OS Recovery image does not require these commands because installation from the BaseOS ISO automatically generates the files.

1. Inventory NVIDIA DGX Spark systems and identify deployments created from a cloned base image or golden image.
2. On deployed systems, inspect /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ecdsa_key.pub, /etc/ssh/ssh_host_ed25519_key, /etc/ssh/ssh_host_ed25519_key.pub, /etc/ssh/ssh_host_rsa_key, /etc/ssh/ssh_host_rsa_key.pub, and /etc/machine-id.
3. Compare these identifiers across systems and against the golden image. Values duplicated across systems or matching the golden image are evidence consistent with this provisioning flaw.
4. After identifiers are regenerated, confirm that every SSH host key and machine-id differs from the original golden image and is unique as required by the deployment.
5. No specific log event or IOC is provided by the source. Reviewing SSH connection records and host-key change alerts may be useful as precautionary monitoring, but such monitoring cannot by itself rule out exposure.