htdy7703/onnx-save-model-external-offset-disk-dos-poc

ONNX save_model external-data offset disk-exhaustion PoC

This PoC demonstrates a verified ONNX issue in the shipped onnx 1.22.0 wheel:

• public API: onnx.save_model()
• trigger: re-saving attacker-controlled ONNX bytes that mark a tensor as external and also carry inline raw_data
• effect: ONNX trusts attacker-controlled external_data.offset and zero-pads the sidecar file up to that offset before writing the payload
• proven impact: a tiny ONNX blob expands into an attacker-sized local file during a normal save/repackage workflow

Repo contents

• repro.py: end-to-end reproducer that builds the malicious ONNX blob in memory and proves large sidecar creation through onnx.save_model(blob, model_path)
• README.md: impact summary and usage notes

What this proves

The PoC builds a 73-byte malicious ModelProto whose initializer:

• is marked data_location=EXTERNAL
• names the sidecar direct.bin
• sets external_data.offset to 67108864
• still embeds a one-byte raw_data payload

It then calls:

onnx.save_model(malicious_blob, model_path)

The expected result is that ONNX creates direct.bin, pads it to 67108864 bytes, writes the payload at that offset, and leaves a sidecar file of 67108865 bytes.

Important caveat

The crafted model is checker-invalid because ONNX requires externally stored tensors not to carry raw_data simultaneously. The issue matters because onnx.save_model() itself accepts raw bytes and does not run onnx.checker.check_model() internally.

Run

python repro.py

Expected signal:

• malicious blob bytes: 73
• checker accepted: False
• sidecar size: 67108865
• payload at attacker offset: True