MBM7/sklearn-pmml-sparsearray-bomb-poc

sklearn-pmml-model SparseArray n Attribute Unbounded Allocation

Status: Preparing for Huntr submission Package: sklearn-pmml-model (PyPI) — pure-Python PMML model loader File / function: sklearn_pmml_model/base.py, parse_sparse_array() Class: CWE-789 (Convergent Untrusted-Length Allocation) Severity: High — a ~1.3KB model file loaded through the library's real, public, documented API consumes ~450MB of memory and takes several seconds; a larger declared value causes the process to be OOM-killed or hang indefinitely.

Summary

PMML (Predictive Model Markup Language) is an XML-based standard for exchanging trained ML models. sklearn-pmml-model parses these files using Python's stdlib xml.etree.cElementTree. When it encounters a <SparseArray> element (used for sparse-encoded data, e.g. support vector storage in SVM models), it allocates a buffer sized directly from the element's declared n attribute before validating it:

# sklearn_pmml_model/base.py
def parse_sparse_array(array):
    ...
    values = [0] * int(array.get('n'))
    indices = [int(i) - 1 for i in array.find('Indices').text.split(' ')]
    ...

array.get('n') is fully attacker-controlled in a crafted PMML file. There is no check on this value before it drives a Python list allocation — and Python lists of integers are notably memory-hungry per element (each entry is a full boxed int object plus a pointer), making this more severe than an equivalent-sized numpy buffer.

Two classic XML attacks were checked first and found NOT applicable

Before finding this schema-specific issue, the two well-known XML parsing attack classes were tested against the library's use of xml.etree.cElementTree, for due diligence:

• Billion Laughs (entity expansion) — blocked. Modern Python's bundled expat enforces a built-in amplification-factor limit; a crafted DOCTYPE with nested entities raises xml.etree.ElementTree.ParseError: limit on input amplification factor (from DTD and entities) breached in well under a second.
• XXE (external entity / local file read) — blocked. ElementTree refuses external entity references by default (reference to external entity in attribute), which is documented, long-standing safe-by-default stdlib behavior.

This finding is not either of those — it's a PMML-schema-specific gap in how <SparseArray>'s n attribute is trusted.

Proof of Concept

poc_sklearn_pmml_sparsearray_bomb.py builds a complete, valid, minimal PMML support-vector regression model — the kind loadable via the library's own public API, sklearn_pmml_model.svm.PMMLNuSVR — containing one <REAL-SparseArray> support vector that declares n="20000000" but has only one real <Indices>/<REAL-Entries> value.

pip install sklearn-pmml-model numpy scikit-learn
python poc_sklearn_pmml_sparsearray_bomb.py

Result

Wrote poc_sparsearray_bomb.pmml: 1266 bytes, declares SparseArray n=20,000,000 (only 1 real index/value)

Loading via the real public API: PMMLNuSVR(pmml='poc_sparsearray_bomb.pmml') ...
  -> loaded, time=8.82s, peak RSS=450.8 MB

The script defaults to n=20,000,000 so it completes in a reasonable time while still clearly demonstrating the amplification (~1:370,000, file bytes to RSS bytes). During research, n=500,000,000 in the same 1266-byte file caused the load to either hang past a 30-second timeout without finishing, or be killed outright by the OS's OOM killer, depending on available memory — see the HUGE_N constant in the script to reproduce that more severe outcome.

Note this loads through the model's real, documented, public loading path — PMMLNuSVR(pmml=path) — not an internal-function-only proof; any application that loads a PMML file with this library and does not pre-validate it is affected exactly as tested here.

Impact

Any service that loads PMML files using sklearn-pmml-model — for example, a model-serving platform or MLOps pipeline that accepts PMML models from users or third parties — can be forced into multi-hundred-megabyte-to-multi-gigabyte memory consumption, or an outright process kill, by a file of a little over a kilobyte.

Suggested fix

In parse_sparse_array(), validate n against the actual number of entries found in the <Indices>/<Entries> children (or against a configurable sane maximum) before allocating [0] * n, and raise a clear error on mismatch.

Disclosure

Please do not use this PoC against production systems you do not own or have explicit permission to test.