Deserialization Flaw in HashNeRF-pytorch Checkpoint Handler

Executive Summary

This vulnerability exists in the HashNeRF-pytorch project, specifically in the function torch.load within the run_nerf.py file. The issue arises because the checkpoint file path argument (ckpt_path) is used directly in torch.load without proper validation or safe deserialization methods.

Since torch.load uses pickle-backed deserialization, loading a malicious checkpoint file can lead to arbitrary code execution. This means an attacker who can place a crafted checkpoint file locally can execute code within the context of the application.

The vulnerability requires local access to the system to place the malicious checkpoint file, and the exploit has been publicly disclosed. A fix is proposed that uses safer loading options like torch.load with weights_only=True to mitigate this risk.

Useful 0 Not Useful 0

Impact Analysis

If exploited, this vulnerability can allow an attacker to execute arbitrary code on your system with the privileges of the user running the HashNeRF-pytorch application.

This can lead to full user-level access to the operating system environment, potentially exposing sensitive information such as datasets, model weights, environment variables, API tokens, SSH keys, and cloud credentials.

Because the attack requires local access to place a malicious checkpoint file, the risk is limited to environments where an attacker can write files locally or influence checkpoint loading paths.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves unsafe deserialization of PyTorch checkpoint files loaded locally via the torch.load function in the run_nerf.py script. Detection involves identifying if untrusted or malicious checkpoint files are being loaded.

You can check for suspicious checkpoint files (.tar or other checkpoint extensions) in directories used by the application, especially those passed as arguments like --ft_path or auto-discovered checkpoint files.

Commands to help detect potential exploitation or presence of malicious checkpoint files include:

• Find checkpoint files in the working directories: `find /path/to/experiment -name '*.tar' -o -name '*.pt' -o -name '*.pth'`
• Check recent file modifications to detect unexpected checkpoint file changes: `ls -ltr /path/to/experiment/*.tar`
• Audit the run_nerf.py script or any scripts invoking torch.load to verify if safe loading options like weights_only=True are used.
• Monitor local user activity for suspicious file creation or execution related to checkpoint files.

Since the attack must be carried out locally, network detection is limited; focus should be on local file integrity and usage monitoring.

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps focus on preventing unsafe deserialization of checkpoint files in the HashNeRF-pytorch project.

• Avoid loading checkpoint files from untrusted or unknown sources.
• Modify the run_nerf.py script to use the safer checkpoint loading method by calling torch.load with the weights_only=True parameter, which restricts deserialization to safe tensor data only.
• Restrict checkpoint file paths and extensions to known safe locations and formats.
• Verify the integrity and authenticity of checkpoint files before loading, for example by using cryptographic signatures or checksums.
• Apply the patch from the pull request titled "Harden checkpoint loading" once it is accepted and merged.

These steps help prevent arbitrary code execution risks associated with malicious checkpoint deserialization.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability allows local attackers to execute arbitrary code through unsafe deserialization of checkpoint files, potentially leading to full OS user-level access.

This access could expose sensitive data such as datasets, model weights, environment variables, API tokens, SSH keys, and cloud credentials.

Exposure of such sensitive information may lead to non-compliance with data protection regulations like GDPR and HIPAA, which require safeguarding personal and sensitive data against unauthorized access.

Therefore, the vulnerability poses a risk to compliance by potentially allowing unauthorized access to protected data.

Useful 0 Not Useful 0