ONNX: symlink-following external-data write lets a local attacker append to victim-writable files

Impact

ONNX's save_external_data builds the external-data file path from the model's own external_data location field and opens it for writing without O_NOFOLLOW/O_EXCL, after a non-atomic isfile() check. A local attacker who can write to the directory where a model is serialized can pre-plant a symlink and redirect the write into any file the serializing user can write - the advisory names ~/.ssh/authorized_keys, cron files and application configs. On a GPU node this matters where model export or conversion runs as a shared service account in a scratch or shared-checkpoint directory: one tenant that can drop a symlink in that directory can turn another user's export job into arbitrary file writes and, via authorized_keys or cron, into code execution as that user. It is an integrity/availability issue only - no direct read of the victim's data - and it requires the victim to actually run an export into the attacker-controlled directory.

Who can reach it

Local user with write access to the directory where the victim serializes ONNX external data. No authentication to ONNX itself is required, but the victim must run a save_external_data-based export while the planted symlink is in place.

What to do

Upgrade the onnx Python package to 1.21.0 or later wherever model export or conversion runs - that is a package upgrade plus a restart of any long-lived conversion or serving process that imports it; no node reboot. Until then, run exports into per-user directories that no other tenant can write, and avoid serializing models whose external_data location field came from an untrusted source.

References